- Feb 03, 2015
-
-
Bjorn Helgaas authored
* pci/config: PCI: xilinx: Convert to use generic config accessors PCI: xgene: Convert to use generic config accessors PCI: tegra: Convert to use generic config accessors PCI: rcar: Convert to use generic config accessors PCI: generic: Convert to use generic config accessors powerpc/powermac: Convert PCI to use generic config accessors powerpc/fsl_pci: Convert PCI to use generic config accessors ARM: ks8695: Convert PCI to use generic config accessors ARM: sa1100: Convert PCI to use generic config accessors ARM: integrator: Convert PCI to use generic config accessors ARM: cns3xxx: Convert PCI to use generic config accessors PCI: Add generic config accessors powerpc/PCI: Add struct pci_ops member names to initialization mn10300/PCI: Add struct pci_ops member names to initialization MIPS: PCI: Add struct pci_ops member names to initialization frv/PCI: Add struct pci_ops member names to initialization
-
- Jan 31, 2015
-
-
Rob Herring authored
Convert the Xilinx host PCI driver to use the generic config access functions. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Michal Simek <michal.simek@xilinx.com> CC: "Sören Brinkmann" <soren.brinkmann@xilinx.com> CC: linux-arm-kernel@lists.infradead.org
-
Rob Herring authored
Convert the xgene host PCI driver to use the generic config access functions. Signed-off-by:
-
Rob Herring authored
Convert the Tegra host PCI driver to use the generic config access functions. Tested-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Rob Herring authored
Convert the rcar-gen2 host PCI driver to use the generic config access functions. This changes the I/O accessors from io(read|write)X to readX/writeX variants which are equivalent on ARM. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> CC: Simon Horman <horms@verge.net.au> CC: linux-sh@vger.kernel.org
-
Rob Herring authored
Convert the generic host PCI driver to use the generic config access functions. Signed-off-by:
Will Deacon <will.deacon@arm.com> CC: linux-arm-kernel@lists.infradead.org
-
Rob Herring authored
Convert the powermac PCI driver to use the generic config access functions. This changes accesses from (in|out)_(8|le16|le32) to readX/writeX variants. I believe these should be equivalent for PCI config space accesses, but confirmation would be nice. Signed-off-by:
-
Rob Herring authored
Convert the fsl_pci driver to use the generic config access functions. This changes accesses from (in|out)_(8|le16|le32) to readX/writeX variants. I believe these should be equivalent for PCI config space accesses, but confirmation would be nice. Signed-off-by:
-
Rob Herring authored
Convert the ks8695 PCI driver to use the generic config access functions. This changes accesses from __raw_readX/__raw_writeX to readX/writeX variants. Signed-off-by:
Greg Ungerer <gerg@uclinux.org> CC: Russell King <linux@arm.linux.org.uk> CC: linux-arm-kernel@lists.infradead.org
-
Rob Herring authored
Convert the sa1100 nanoengine PCI driver to use the generic config access functions. Change accesses from __raw_readX/__raw_writeX to readX/writeX variants. This removes the spinlock because it is unnecessary. The config read and write functions are already protected with a spinlock. Signed-off-by:
-
- Jan 29, 2015
-
-
Rob Herring authored
Convert the integrator PCI driver to use the generic config access functions. This changes accesses from __raw_readX/__raw_writeX to readX/writeX variants. The spinlock is removed because it is unnecessary. The config read and write functions are already protected with a spinlock and no access can occur during the .pre_init function. [arnd: remove unused "flags"] Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> CC: Russell King <linux@arm.linux.org.uk> CC: linux-arm-kernel@lists.infradead.org
-
- Jan 28, 2015
-
-
Bjorn Helgaas authored
* pci/enumeration: PCI: Generate uppercase hex for modalias var in uevent * pci/hotplug: PCI: pciehp: Handle surprise add even if surprise removal isn't supported * pci/resource: PCI: Fix infinite loop with ROM image of size 0 * pci/virtualization: PCI: Add Wellsburg (X99) to Intel PCH root port ACS quirk PCI: Add DMA alias quirk for Adaptec 3405 PCI: Add ACS quirk for Emulex NICs PCI: Mark AMD/ATI VGA devices that don't reset on D3hot->D0 transition PCI: Add flag for devices that don't reset on D3hot->D0 transition PCI: Mark Atheros AR93xx to avoid bus reset PCI: Add flag for devices where we can't use bus reset
-
Bjorn Helgaas authored
Merge branches 'pci/host-keystone', 'pci/host-tegra', 'pci/host-xgene' and 'pci/host-xilinx' into next * pci/host-keystone: PCI: keystone: Fix misspelling of current function in debug output * pci/host-tegra: PCI: tegra: Remove unnecessary tegra_pcie_fixup_bridge() * pci/host-xgene: PCI: xgene: Include clk.h instead of clk-private.h * pci/host-xilinx: PCI: xilinx: Fix harmless format string warning
-
- Jan 24, 2015
-
-
Michel Dänzer authored
If the image size would ever read as 0, pci_get_rom_size() could keep processing the same image over and over again. Exit the loop if we ever read a length of zero. This fixes a soft lockup on boot when the radeon driver calls pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card. [bhelgaas: changelog, reference] Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973 Reported-by:
Federico <federicotg@gmail.com> Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> CC: stable@vger.kernel.org
-
Stephen Boyd authored
This driver should be including clk.h as it's a clock consumer, not a clock provider that needs to register clocks early. Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Tanmay Inamdar <tinamdar@apm.com>
-
Alex Williamson authored
Intel has confirmed that the Wellsburg chipset, while not reporting ACS, does provide the proper isolation through the RCBA/BSPR registers, so the same quirk works for this set of device IDs. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Don Dugger <donald.d.dugger@intel.com>
-
Alex Williamson authored
The Adaptec 3405 is actually an Intel 80333 I/O processor where the exposed device at 0e.0 is actually the address translation unit of the I/O processor and a hidden, private device at 01.0 masters the DMA for the device. Create a fixed alias between the exposed and hidden devfn so we can enable the IOMMU. Scenarios like this are potentially likely for any device incorporating this I/O processor, so this little bit of abstraction with the fixed alias table should make future additions trivial. Without this fix, booting a system with the Intel IOMMU enabled and an Adaptec 3405 at 02:0e.0 results in a flood of errors like this: dmar: DRHD: handling fault status reg 3 dmar: DMAR:[DMA Write] Request device [02:01.0] fault addr ffbff000 DMAR:[fault reason 02] Present bit in context entry is clear [bhelgaas: changelog, comment] Signed-off-by:
-
Arnd Bergmann authored
The xilinx PCIe driver prints a register value whose type is propagated to the type returned by the GENMASK() macro. Unfortunately, that type has recently changed as the result of a bug fix, so now we get a warning about the type: drivers/pci/host/pcie-xilinx.c: In function 'xilinx_pcie_clear_err_interrupts': drivers/pci/host/pcie-xilinx.c:154:3: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=] Change the code so we always print the number as an 'unsigned long' type to avoid the warning. The original code was fine on 32-bit architectures but not on 64-bit. Now it works as expected on both. Fixes: 00b4d9a1 ("bitops: Fix shift overflow in GENMASK macros") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Maxime Coquelin <maxime.coquelin@st.com>
-
- Jan 23, 2015
-
-
Rob Herring authored
Convert the cns3xxx PCI driver to use the generic config access functions. This changes accesses from __raw_readl/__raw_writel to readl/writel. [arnd: remove extra open parenthesis] Signed-off-by:
Krzysztof Hałasa <khalasa@piap.pl> CC: Russell King <linux@arm.linux.org.uk> CC: linux-arm-kernel@lists.infradead.org
-
Rob Herring authored
Many PCI controllers' configuration space accesses are memory-mapped and vary only in address calculation and access checks. There are 2 main access methods: a decoded address space such as ECAM or a single address and data register similar to x86. This implementation can support both cases as well as be used in cases that need additional pre- or post-access handling. Add a new pci_ops member, map_bus, which can do access checks and any necessary setup. It returns the address to use for the configuration space access. The access types supported are 32-bit only accesses or correct byte, word, or dword sized accesses. Tested-by:
-
Rob Herring authored
Some instances of pci_ops initialization rely on the read/write members' location in the struct. This is fragile and may break when adding new members to the beginning of the struct. No functional change. Signed-off-by:
-
Rob Herring authored
Some instances of pci_ops initialization rely on the read/write members' location in the struct. This is fragile and may break when adding new members to the beginning of the struct. No functional change. Signed-off-by:
-
Rob Herring authored
Some instances of pci_ops initialization rely on the read/write members' location in the struct. This is fragile and may break when adding new members to the beginning of the struct. No functional change. Signed-off-by:
-
Rob Herring authored
Some instances of pci_ops initialization rely on the read/write members' location in the struct. This is fragile and may break when adding new members to the beginning of the struct. No functional change. Signed-off-by:
-
- Jan 22, 2015
-
-
Bjorn Helgaas authored
The PCIe spec (r3.0, sec 7.8.9) says Hot-Plug Surprise indicates support for surprise *removal*, but pciehp checked this to determine if it should handle presence detect interrupts for device *addition*. Allow surprise device addition even if the slot doesn't advertise support for surprise removal. Keith has a platform with slots for front-loading SFF devices. The slots do not have attention buttons and do not support surprise removal, but they do have presence detect. In that case, we still want to use presence detect for device addition. Keith's original patch handled surprise insertions only if Hot-Plug Capable is set. I think that test is superfluous because pciehp only claims slots that advertise Hot-Plug Capable (see get_port_device_capability()). Link: http://lkml.kernel.org/r/1419275223-14602-1-git-send-email-keith.busch@intel.com Based-on-patch-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Rajat Jain <rajatxjain@gmail.com>
-
- Jan 17, 2015
-
-
Vasundhara Volam authored
As Skyhawk and BE3-R (both multi-function devices) don't advertise the PCI-ACS capability, the vfio driver places all the functions of these devices in a single IOMMU group. Attaching (via PCI-passthru) two different Skyhawk/BE3-R partitions (nPAR, Flex, etc. PFs) using vfio, to different guests doesn't work as vfio only allows functions in *different* IOMMU groups to be assigned to different guests. As peer-to-peer access between PFs in Skyhawk/BE3-R is not possible, we can treat them as "fully isolated" even though the device doesn't advertise ACS. Add a PCI quirk for Skyhawk and BE3-R chips to fix this problem. Signed-off-by:
Vasundhara Volam <vasundhara.volam@emulex.com> Signed-off-by:
Sathya Perla <sathya.perla@emulex.com> Signed-off-by:
-
Alex Williamson authored
Some AMD/ATI GPUs report NoSoftRst- to indicate that they perform a reset when software transitions them from D3hot to D0, but there is no apparent effect on the device: the monitor remains synced and the framebuffer contents are retained. Callers of pci_reset_function() don't necessarily have a way to validate whether a reset was effective, so we don't want to rely on NoSoftRst if it's known to be inaccurate. Returning an error in such cases appears to be the better option. For users like vfio-pci, this allows the driver to escalate to the bus reset interfaces. If a device lives on the root bus, there's really no further escalation path, so we exempt PM reset as potentially better than nothing. Signed-off-by:
-
Alex Williamson authored
Per the PCI Power Management spec r1.2, sec 3.2.4, a device that advertises No_Soft_Reset == 0 in the PMCSR register (reported by lspci as "NoSoftRst-") should perform an internal reset when transitioning from D3hot to D0 via software control. Configuration context is lost and the device requires a full reinitialization sequence. Unfortunately the definition of "internal reset", beyond the application of the configuration context, is largely left to the interpretation of the specific device. Some devices don't seem to perform an "internal reset" even if they report No_Soft_Reset == 0. We still need to honor the PCI specification and restore PCI config context in the event that we do a PM reset, so we don't cache and modify the PCI_PM_CTRL_NO_SOFT_RESET bit for the device, but for interfaces where the intention is to reset the device, like pci_reset_function(), we need a mechanism to flag that PM reset (a D3hot->D0 transition) doesn't perform any significant "internal reset" of the device. Signed-off-by:
-
Alex Williamson authored
Reports against the TL-WDN4800 card indicate that PCI bus reset of this Atheros device cause system lock-ups and resets. I've also been able to confirm this behavior on multiple systems. The device never returns from reset and attempts to access config space of the device after reset result in hangs. Blacklist bus reset for the device to avoid this issue. [bhelgaas: This regression appeared in v3.14. Andreas bisected it to 425c1b22 ("PCI: Add Virtual Channel to save/restore support"), but we don't understand the mechanism by which that commit affects the reset path.] [bhelgaas: changelog, references] Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org Reported-by:
Andreas Hartmann <andihartmann@freenet.de> Tested-by:
-
Alex Williamson authored
Enable a mechanism for devices to quirk that they do not behave when doing a PCI bus reset. We require a modest level of spec compliant behavior in order to do a reset, for instance the device should come out of reset without throwing errors and PCI config space should be accessible after reset. This is too much to ask for some devices. Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org Signed-off-by:
-
- Jan 10, 2015
-
-
Julia Lawall authored
Replace a misspelled function name by %s and then __func__. The function name contains pcie, not pci as in the string. This was done using Coccinelle, including the use of Levenshtein distance, as proposed by Rasmus Villemoes. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
Murali Karicheri <m-karicheri2@ti.com>
-
Ricardo Ribalda Delgado authored
Some implementations of modprobe fail to load the driver for a PCI device automatically because the "interface" part of the modalias from the kernel is lowercase, and the modalias from file2alias is uppercase. The "interface" is the low-order byte of the Class Code, defined in PCI r3.0, Appendix D. Most interface types defined in the spec do not use alpha characters, so they won't be affected. For example, 00h, 01h, 10h, 20h, etc. are unaffected. Print the "interface" byte of the Class Code in uppercase hex, as we already do for the Vendor ID, Device ID, Class, etc. Commit 89ec3dcf ("PCI: Generate uppercase hex for modalias interface class") fixed only half of the problem. Some udev implementations rely on the uevent file and not the modalias file. Fixes: d1ded203 ("PCI: add MODALIAS to hotplug event for pci devices") Fixes: 89ec3dcf ("PCI: Generate uppercase hex for modalias interface class") Signed-off-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: stable@vger.kernel.org
-
- Dec 30, 2014
-
-
Bjorn Helgaas authored
Merge branches 'pci/host-keystone', 'pci/host-layerscape', 'pci/host-rcar' and 'pci/host-tegra' into next * pci/host-keystone: PCI: keystone: Fix error handling of irq_of_parse_and_map() * pci/host-layerscape: PCI: layerscape: Fix platform_no_drv_owner.cocci warnings * pci/host-rcar: PCI: rcar: Fix error handling of irq_of_parse_and_map() * pci/host-tegra: PCI: tegra: Remove unnecessary tegra_pcie_fixup_bridge()
-
Bjorn Helgaas authored
* pci/domain: ARM/PCI: Move to generic PCI domains CNS3xxx: Remove artificial dependency on pci_sys_data domain. PCI: Move domain assignment from arm64 to generic code * pci/hotplug: PCI: Delete unnecessary NULL pointer checks
-
- Dec 28, 2014
-
-
Lorenzo Pieralisi authored
Most if not all ARM PCI host controller device drivers either ignore the domain field in the pci_sys_data structure or just increment it every time a host controller is probed, using it as a domain counter. Therefore, instead of relying on pci_sys_data to stash the domain number in a standard location, ARM pcibios code can be moved to the newly introduced generic PCI domains code, implemented in commits: 41e5c0f8 ("of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr()") 670ba0c8 ("PCI: Add generic domain handling") ARM code is made to select PCI_DOMAINS_GENERIC by default, which builds core PCI code that assigns the domain number through the generic function: void pci_bus_assign_domain_nr(...) that relies on a DT property to define the domain number or falls back to a counter according to a predefined logic; its usage replaces the current domain assignment code in PCI host controllers present in the kernel. Tested-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Yijing Wang <wangyijing@huawei.com> Reviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> # mvebu Acked-by:
Russell King <rmk+kernel@arm.linux.org.uk> Acked-by:
Jingoo Han <jg1.han@samsung.com> Acked-by:
Phil Edworthy <phil.edworthy@renesas.com> Acked-by:
-
Lorenzo Pieralisi authored
On cns3xxx platforms the PCI controller probing code relies on an artificial dependency on the domain number to look-up the internal data structures. This patch reworks the host controller control data structure and adds a domain equivalent field named port in it so that the dependency on pci_sys_data domain field can be eventually removed. Acked-by:
-
Lorenzo Pieralisi authored
The current logic in arm64 pci_bus_assign_domain_nr() is flawed in that depending on the host controller configuration for a platform and the initialization sequence, core code may end up allocating PCI domain numbers from both DT and the generic domain counter, which would result in PCI domain allocation aliases/errors. Fix the logic behind the PCI domain number assignment and move the resulting code to the PCI core so the same domain allocation logic is used on all platforms that select CONFIG_PCI_DOMAINS_GENERIC. [bhelgaas: tidy changelog] Signed-off-by:
Liviu Dudau <Liviu.Dudau@arm.com> Acked-by:
-
- Dec 27, 2014
-
-
Markus Elfring authored
The pci_dev_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Lucas Stach authored
The bridge setup is already done by generic code while scanning the buses. Do not duplicate (or potentially alter) this setup as a fixup. Tested-by:
Alexandre Courbot <acourbot@nvidia.com> Tested-by:
-
Lucas Stach authored
The bridge setup is already done by generic code while scanning the buses. Do not duplicate (or potentially alter) this setup as a fixup. Tested-by:
-
