Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 12 6月, 2014 1 次提交
  3. 31 5月, 2014 6 次提交
  5. 30 5月, 2014 3 次提交
  7. 29 5月, 2014 1 次提交
    • A
      PCI: Introduce new device binding path using pci_dev.driver_override · 782a985d
      由 Alex Williamson 提交于 
      The driver_override field allows us to specify the driver for a device
rather than relying on the driver to provide a positive match of the
device.  This shortcuts the existing process of looking up the vendor and
device ID, adding them to the driver new_id, binding the device, then
removing the ID, but it also provides a couple advantages.

First, the above existing process allows the driver to bind to any device
matching the new_id for the window where it's enabled.  This is often not
desired, such as the case of trying to bind a single device to a meta
driver like pci-stub or vfio-pci.  Using driver_override we can do this
deterministically using:

  echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override
  echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
  echo 0000:03:00.0 > /sys/bus/pci/drivers_probe

Previously we could not invoke drivers_probe after adding a device to
new_id for a driver as we get non-deterministic behavior whether the driver
we intend or the standard driver will claim the device.  Now it becomes a
deterministic process, only the driver matching driver_override will probe
the device.

To return the device to the standard driver, we simply clear the
driver_override and reprobe the device:

  echo > /sys/bus/pci/devices/0000:03:00.0/driver_override
  echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
  echo 0000:03:00.0 > /sys/bus/pci/drivers_probe

Another advantage to this approach is that we can specify a driver override
to force a specific binding or prevent any binding.  For instance when an
IOMMU group is exposed to userspace through VFIO we require that all
devices within that group are owned by VFIO.  However, devices can be
hot-added into an IOMMU group, in which case we want to prevent the device
from binding to any driver (override driver = "none") or perhaps have it
automatically bind to vfio-pci.  With driver_override it's a simple matter
for this field to be set internally when the device is first discovered to
prevent driver matches.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: NAlexander Graf <agraf@suse.de>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      782a985d
  9. 28 5月, 2014 16 次提交
  11. 24 5月, 2014 11 次提交
    • B
      PCI: Add resource allocation comments · 67d29b5c
      由 Bjorn Helgaas 提交于 
      Add comments in the code to match the allocation strategy of 7c671426dfc3
("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources").

No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      67d29b5c
    • B
      PCI: Simplify __pci_assign_resource() coding style · d3689df0
      由 Bjorn Helgaas 提交于 
      If an allocation succeeds, we can return success immediately.  Then we
don't have to test for success in the subsequent code.

No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d3689df0
    • B
      PCI: Change pbus_size_mem() return values to be more conventional · 30afe8d0
      由 Bjorn Helgaas 提交于 
      pbus_size_mem() previously returned 0 for failure and 1 for success.
Change it to return -ENOSPC for failure and 0 for success.

No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      30afe8d0
    • Y
      PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources · 5b285415
      由 Yinghai Lu 提交于 
      This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.

Previously we put all prefetchable resources in the prefetchable bridge
window.  If any of those resources was 32-bit only, we restricted the
window to be below 4GB.

After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window.  We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.

With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.

The new strategy is:

  1) If the prefetchable window is 64 bits wide, we put only 64-bit
     prefetchable resources in it.  Any 32-bit prefetchable resources go in
     the non-prefetchable window.

  2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
     prefetchable resources in it.

  3) If there is no prefetchable window, all MMIO resources go in the
     non-prefetchable window.

This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window.  We previously assigned prefetchable
space, but now we'll assign non-prefetchable space.  This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB.  In those cases, the old strategy would work and would have
better performance.

[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151Tested-by: NGuo Chao <yan@linux.vnet.ibm.com>
Tested-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      5b285415
    • A
      PCI: Support BAR sizes up to 8GB · 14c8530d
      由 Alan 提交于 
      This is needed for some of the Xeon Phi type systems.

[bhelgaas: added Nikhil, use ARRAY_SIZE() to connect with decl, folded in
Kevin's "order < 0" fix to ARRAY_SIZE() usage]
Signed-off-by: NNikhil P Rao <nikhil.rao@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      14c8530d
    • B
      PCI: Don't add disabled subtractive decode bus resources · d739a099
      由 Bjorn Helgaas 提交于 
      For a subtractive decode bridge, we previously added and printed all
resources of the primary bus, even if they were not valid.  In the example
below, the bridge 00:1c.3 has no windows enabled, so there are no valid
resources on bus 02.  But since 02:00.0 is subtractive decode bridge, we
add and print all those invalid resources, which don't really make sense:

  pci 0000:00:1c.3: PCI bridge to [bus 02-03]
  pci 0000:02:00.0: PCI bridge to [bus 03] (subtractive decode)
  pci 0000:02:00.0:   bridge window [??? 0x00000000 flags 0x0] (subtractive decode)

Add and print the subtractively-decoded resources only if they are valid.

There's an example in the dmesg log attached to the bugzilla below (but
this patch doesn't fix the bug reported there).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=73141Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d739a099
    • B
      PCI: Don't print anything while decoding is disabled · 26370fc6
      由 Bjorn Helgaas 提交于 
      If the console is a PCI device, and we try to print to it while its
decoding is disabled, the system will hang.  This particular printk hasn't
caused a problem yet, but it could, so this fixes it.

See also 0ff9514b ("PCI: Don't print anything while decoding is
disabled").
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      26370fc6
    • B
      PCI: Don't set BAR to zero if dma_addr_t is too small · 31e9dd25
      由 Bjorn Helgaas 提交于 
      If a BAR is above 4GB and our dma_addr_t is too small, don't clear the BAR
to zero: that doesn't disable the BAR, and it makes it more likely that the
BAR will conflict with things if we turn on the memory enable bit (as we
will at "out:" if the device was already enabled at the handoff).

We should also print the BAR info and its original size so we can follow
the process when we try to assign space to it.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      31e9dd25
    • B
      PCI: Don't convert BAR address to resource if dma_addr_t is too small · 72dc5601
      由 Bjorn Helgaas 提交于 
      If dma_addr_t is too small to represent the BAR value,
pcibios_bus_to_resource() will fail, so just remember the BAR size directly
in the resource.  The resource is already marked UNSET, so we know the
address isn't valid anyway.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      72dc5601
    • B
      PCI: Reject BAR above 4GB if dma_addr_t is too small · d1a313e4
      由 Bjorn Helgaas 提交于 
      We can only handle BARs above 4GB if dma_addr_t (not resource_size_t) is 64
bits wide.  If we have a 64-bit resource_size_t and a 32-bit dma_addr_t,
we can't deal with BARs above 4GB.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d1a313e4
    • B
      PCI: Fail safely if we can't handle BARs larger than 4GB · 23b13bc7
      由 Bjorn Helgaas 提交于 
      We can only handle BARs larger than 4GB if both dma_addr_t and
resource_size_t are 64 bits wide.  If dma_addr_t is 32 bits, we can't
represent all the bus addresses, and if resource_size_t is 32 bits, we
can't represent all the CPU addresses.

Previously we cleared res->flags (at "fail:") for resources that were too
large.  That means we think the BAR doesn't exist at all, which in turn
means that we could enable the device even though we can't keep track of
where the BAR is and we can't make sure it doesn't overlap something else.

This preserves the type flags (MEM/IO) so we can keep from enabling the
device.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      23b13bc7
  13. 23 5月, 2014 1 次提交
  15. 21 5月, 2014 1 次提交
    • A
      PCI: Mark RTL8110SC INTx masking as broken · 3cb30b73
      由 Alex Williamson 提交于 
      INTx masking does not work on this device.  To see this, configure the
network device UP on an active network, note that the interrupt count
continues to increment for the device in /proc/interrupts.  Use setpci to
set the PCI_COMMAND_INTX_DISABLE bit in the PCI_COMMAND register.  As
expected, the interrupt count ceases to increment.  However, reading the
PCI_STATUS_INTERRUPT bit of the PCI_STATUS register does not indicate that
interrupts are pending and clearing PCI_COMMAND_INTX_DISABLE in the
PCI_COMMAND register does not allow the device to continue operation.

This does not affect operation of the host r8169 driver, but it does
prevent the device from being functional when assigned to a VM, such as
with QEMU and VFIO.  The guest driver successfully probes the device, but
there is no traffic.  Mark INTx masking as broken, allowing the more
restrictive APIC masking to be used instead.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      3cb30b73