summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2014-05-28Merge branches 'pci/hotplug', 'pci/pci_is_bridge' and 'pci/virtualization' ↵Bjorn Helgaas22-45/+154
into next * pci/hotplug: PCI: cpqphp: Fix possible null pointer dereference NVMe: Implement PCIe reset notification callback PCI: Notify driver before and after device reset * pci/pci_is_bridge: pcmcia: Use pci_is_bridge() to simplify code PCI: pciehp: Use pci_is_bridge() to simplify code PCI: acpiphp: Use pci_is_bridge() to simplify code PCI: cpcihp: Use pci_is_bridge() to simplify code PCI: shpchp: Use pci_is_bridge() to simplify code PCI: rpaphp: Use pci_is_bridge() to simplify code sparc/PCI: Use pci_is_bridge() to simplify code powerpc/PCI: Use pci_is_bridge() to simplify code ia64/PCI: Use pci_is_bridge() to simplify code x86/PCI: Use pci_is_bridge() to simplify code PCI: Use pci_is_bridge() to simplify code PCI: Add new pci_is_bridge() interface PCI: Rename pci_is_bridge() to pci_has_subordinate() * pci/virtualization: PCI: Introduce new device binding path using pci_dev.driver_override Conflicts: drivers/pci/pci-sysfs.c
2014-05-28Merge branches 'pci/host-exynos', 'pci/host-rcar' and 'pci/amd-numa' into nextBjorn Helgaas9-36/+1224
* pci/host-exynos: PCI: exynos: Remove unnecessary OOM messages * pci/host-rcar: PCI: rcar: Add gen2 device tree support PCI: rcar: Add R-Car PCIe device tree bindings PCI: rcar: Add MSI support for PCIe PCI: rcar: Add Renesas R-Car PCIe driver PCI: rcar: Use new OF interrupt mapping when possible * pci/amd-numa: x86/PCI: Clean up and mark early_root_info_init() as deprecated x86/PCI: Work around AMD Fam15h BIOSes that fail to provide _PXM x86/PCI: Warn if we have to "guess" host bridge node information
2014-05-28PCI: Introduce new device binding path using pci_dev.driver_overrideAlex Williamson5-3/+85
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: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Alexander Graf <agraf@suse.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-28PCI: rcar: Add gen2 device tree supportBen Dooks2-2/+95
Add device tree probing support to the 'pci-rcar-gen2' driver. [Sergei: numerous fixes/cleanups/additions] [bhelgaas: whitespace fix] Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Arnd Bergmann <arnd@arndb.de>
2014-05-27PCI: cpqphp: Fix possible null pointer dereferenceRickard Strandqvist1-1/+2
There is otherwise a risk of a null pointer dereference. Found by cppcheck, a static code analysis program. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: rcar: Add R-Car PCIe device tree bindingsPhil Edworthy1-0/+47
This patch adds the bindings for the R-Car PCIe driver. The driver resides under drivers/pci/host/pcie-rcar.c Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-05-27PCI: rcar: Add MSI support for PCIePhil Edworthy1-1/+241
Add MSI support to the R-Car PCIe driver. Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-05-27PCI: rcar: Add Renesas R-Car PCIe driverPhil Edworthy3-0/+775
This PCIe Host driver currently does not support MSI, so cards fall back to INTx interrupts. Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-05-27PCI: exynos: Remove unnecessary OOM messagesJingoo Han1-3/+1
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27pcmcia: Use pci_is_bridge() to simplify codeYijing Wang1-2/+1
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: pciehp: Use pci_is_bridge() to simplify codeYijing Wang1-2/+1
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: acpiphp: Use pci_is_bridge() to simplify codeYijing Wang1-2/+1
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: cpcihp: Use pci_is_bridge() to simplify codeYijing Wang1-2/+1
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: shpchp: Use pci_is_bridge() to simplify codeYijing Wang1-2/+1
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: rpaphp: Use pci_is_bridge() to simplify codeYijing Wang1-2/+1
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-05-27sparc/PCI: Use pci_is_bridge() to simplify codeYijing Wang1-2/+1
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: David S. Miller <davem@davemloft.net>
2014-05-27powerpc/PCI: Use pci_is_bridge() to simplify codeYijing Wang2-4/+2
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27ia64/PCI: Use pci_is_bridge() to simplify codeYijing Wang1-3/+1
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27x86/PCI: Use pci_is_bridge() to simplify codeYijing Wang1-3/+1
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: Use pci_is_bridge() to simplify codeYijing Wang3-12/+3
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: Add new pci_is_bridge() interfaceYijing Wang1-0/+13
Add a helper function to check a device's header type for PCI bridge or CardBus bridge. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: Rename pci_is_bridge() to pci_has_subordinate()Yijing Wang2-5/+5
Previously, pci_is_bridge() returned true only when a subordinate bus existed. Rename pci_is_bridge() to pci_has_subordinate() to better indicate what we're checking. No functional change. [bhelgaas: changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27NVMe: Implement PCIe reset notification callbackKeith Busch1-0/+11
Quiesce and shutdown the device prior to reset, then restart the device and resume IO after. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: Notify driver before and after device resetKeith Busch2-0/+24
Notify a PCI device driver when its device's access is about to be disabled for an impending reset attempt, then after the attempt completes and device access is restored. The notification is via the pci_error_handlers interface. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27x86/PCI: Clean up and mark early_root_info_init() as deprecatedSuravee Suthikulpanit1-30/+38
early_root_info_init() is now deprecated in favor of info in ACPI. Add a note to that effect. Also, clean up the code a bit. There is no functional change. Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-26Merge branches 'dma-api', 'pci/virtualization', 'pci/msi', 'pci/misc' and ↵Bjorn Helgaas27-465/+613
'pci/resource' into next * dma-api: iommu/exynos: Remove unnecessary "&" from function pointers DMA-API: Update dma_pool_create ()and dma_pool_alloc() descriptions DMA-API: Fix duplicated word in DMA-API-HOWTO.txt DMA-API: Capitalize "CPU" consistently sh/PCI: Pass GAPSPCI_DMA_BASE CPU & bus address to dma_declare_coherent_memory() DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t DMA-API: Clarify physical/bus address distinction * pci/virtualization: PCI: Mark RTL8110SC INTx masking as broken * pci/msi: PCI/MSI: Remove pci_enable_msi_block() * pci/misc: PCI: Remove pcibios_add_platform_entries() s390/pci: use pdev->dev.groups for attribute creation PCI: Move Open Firmware devspec attribute to PCI common code * pci/resource: PCI: Add resource allocation comments PCI: Simplify __pci_assign_resource() coding style PCI: Change pbus_size_mem() return values to be more conventional PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources PCI: Support BAR sizes up to 8GB resources: Clarify sanity check message PCI: Don't add disabled subtractive decode bus resources PCI: Don't print anything while decoding is disabled PCI: Don't set BAR to zero if dma_addr_t is too small PCI: Don't convert BAR address to resource if dma_addr_t is too small PCI: Reject BAR above 4GB if dma_addr_t is too small PCI: Fail safely if we can't handle BARs larger than 4GB x86/gart: Tidy messages and add bridge device info x86/gart: Replace printk() with pr_info() x86/PCI: Move pcibios_assign_resources() annotation to definition x86/PCI: Mark ATI SBx00 HPET BAR as IORESOURCE_PCI_FIXED x86/PCI: Don't try to move IORESOURCE_PCI_FIXED resources x86/PCI: Fix Broadcom CNB20LE unintended sign extension
2014-05-26iommu/exynos: Remove unnecessary "&" from function pointersBjorn Helgaas1-7/+7
Remove unnecessary "&" from function pointers in exynos_iommu_ops. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2014-05-26DMA-API: Update dma_pool_create ()and dma_pool_alloc() descriptionsGioh Kim1-4/+4
Use "boundary" to be more descriptive than "alloc" in the dma_pool_create() documentation. Replace "SLAB_KERNEL" and "SLAB_ATOMIC" with the correct "GFP_KERNEL" and "GFP_ATOMIC." [bhelgaas: changelog] Signed-off-by: Gioh Kim <gioh.kim@lge.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-26DMA-API: Fix duplicated word in DMA-API-HOWTO.txtEmilio López1-4/+4
"coherent" is written twice when it should be just once. Signed-off-by: Emilio López <emilio@elopez.com.ar> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-26DMA-API: Capitalize "CPU" consistentlyBjorn Helgaas2-10/+10
Sometimes we used "cpu," other times "CPU." Use "CPU" consistently. Suggested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Add resource allocation commentsBjorn Helgaas2-31/+62
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: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Simplify __pci_assign_resource() coding styleBjorn Helgaas1-4/+6
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: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Change pbus_size_mem() return values to be more conventionalBjorn Helgaas1-14/+21
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: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resourcesYinghai Lu2-53/+117
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=74151 Tested-by: Guo Chao <yan@linux.vnet.ibm.com> Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Support BAR sizes up to 8GBAlan1-5/+10
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: Nikhil P Rao <nikhil.rao@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23resources: Clarify sanity check messageBjorn Helgaas1-5/+2
The resource map sanity check message is a bit confusing. Change it to be more readable: -resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 +resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than pnp 00:01 [mem 0xfed10000-0xfed13fff] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Don't add disabled subtractive decode bus resourcesBjorn Helgaas1-1/+1
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=73141 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Don't print anything while decoding is disabledBjorn Helgaas1-4/+6
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 0ff9514b579b ("PCI: Don't print anything while decoding is disabled"). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Don't set BAR to zero if dma_addr_t is too smallBjorn Helgaas1-6/+7
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: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Don't convert BAR address to resource if dma_addr_t is too smallBjorn Helgaas1-2/+3
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: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Reject BAR above 4GB if dma_addr_t is too smallBjorn Helgaas1-1/+1
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: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Fail safely if we can't handle BARs larger than 4GBBjorn Helgaas1-6/+12
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: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23x86/gart: Tidy messages and add bridge device infoBjorn Helgaas1-16/+21
Print the AGP bridge info the same way as the rest of the kernel, e.g., "0000:00:04.0" instead of "00:04:00". Also print the AGP aperture address range the same way we print resources, and label it explicitly as a bus address range. No functional change except the message changes. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23x86/gart: Replace printk() with pr_info()Bjorn Helgaas1-28/+26
Replace printk() with pr_info(), pr_err(), etc. Define pr_fmt() to prefix output with "AGP: ". No functional change except the addition of "AGP: " prefix in dmesg output. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23x86/PCI: Move pcibios_assign_resources() annotation to definitionBjorn Helgaas1-6/+6
Move the pcibios_assign_resources() fs_initcall annotation next to the function definition. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-22PCI: Remove pcibios_add_platform_entries()Sebastian Ott2-11/+0
Remove pcibios_add_platform_entries(). Architecture-specific attributes can be achieved by setting pdev->dev.groups. Link: https://lkml.kernel.org/r/alpine.LFD.2.11.1404141101500.1529@denkbrett Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-22s390/pci: use pdev->dev.groups for attribute creationSebastian Ott3-40/+16
Let the driver core handle attribute creation by putting all s390 specific pci attributes in an attribute group which is referenced by pdev->dev.groups in pcibios_add_device. Link: https://lkml.kernel.org/r/alpine.LFD.2.11.1404141101500.1529@denkbrett Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-05-21x86/PCI: Work around AMD Fam15h BIOSes that fail to provide _PXMSuravee Suthikulpanit1-4/+21
The BIOS is supposed to provide ACPI _PXM methods for PCI host bridges if it cares about platform topology. But some BIOSes do not, so add Fam15h to the list of CPUs for which we fall back to reading node numbers from the hardware. Note that pci_acpi_scan_root() warns about the BIOS bug if we use this information because (1) the hardware node numbers are not necessarily compatible with other logical node numbers from ACPI, and (2) the lack of _PXM forces OS updates that would not otherwise be required. [bhelgaas: changelog, comments] Link: https://bugzilla.kernel.org/show_bug.cgi?id=72051 Tested-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Borislav Petkov <bp@suse.de> Cc: Robert Richter <rric@kernel.org> Cc: Daniel J Blueman <daniel@numascale.com> Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
2014-05-21x86/PCI: Warn if we have to "guess" host bridge node informationMyron Stowe1-1/+5
The vast majority of platforms are not supplying ACPI _PXM (proximity) information corresponding to host bridge (PNP0A03/PNP0A08) devices resulting in sysfs "numa_node" values of -1 (NUMA_NO_NODE): # for i in /sys/devices/pci0000\:00/*/numa_node; do cat $i; done | uniq -1 # find /sys/ -name "numa_node" | while read fname; do cat $fname; \ done | uniq -1 AMD based platforms provide a fall-back for this situation via amd_bus.c. These platforms snoop out the information by directly reading specific registers from the Northbridge and caching them via alloc_pci_root_info(). Later during boot processing when host bridges are discovered - pci_acpi_scan_root() - the kernel looks for their corresponding ACPI _PXM method - drivers/acpi/numa.c::acpi_get_node(). If the BIOS supplied a _PXM method then that node (proximity) value is associated. If the BIOS did not supply a _PXM method *and* the platform is AMD-based, the fall-back cached values obtained directly from the Northbridge are used; otherwise, "NUMA_NO_NODE" is associated. There are a number of issues with this fall-back mechanism the most notable being that amd_bus.c extracts a 3-bit number from a CPU register and uses it as the node number. The node numbers used by Linux are logical and there's no reason they need to be identical to settings in the CPU registers. So if we have some node information obtained in the normal way (from _PXM, SLIT, SRAT, etc.) and some from amd_bus.c, there's no reason to believe they will be compatible. This patch warns when this situation occurs: pci_root PNP0A08:00: [Firmware Bug]: no _PXM; falling back to node 0 from hardware (may be inconsistent with ACPI node numbers) Link: https://bugzilla.kernel.org/show_bug.cgi?id=72051 Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20sh/PCI: Pass GAPSPCI_DMA_BASE CPU & bus address to dma_declare_coherent_memory()Bjorn Helgaas1-3/+15
dma_declare_coherent_memory() needs both the CPU physical address and the bus address of the device memory. They are the same on this platform, but in general we should use pcibios_resource_to_bus() to account for any address translation done by the PCI host bridge. This makes no difference on Dreamcast, but is safer if the usage is copied to future drivers. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de> CC: Magnus Damm <damm@opensource.se> CC: linux-sh@vger.kernel.org
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-01 07:31:55 +0000