kernel/git/stable/linux.git/drivers/pci/access.c, branch linux-4.2.y

PCI: Use function 0 VPD for identical functions, regular VPD for others

2015-10-22T21:49:22+00:00

commit da2d03ea27f6ed9d2005a67b20dd021ddacf1e4d upstream. 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0") added PCI_DEV_FLAGS_VPD_REF_F0. Previously, we set the flag on every non-zero function of quirked devices. If a function turned out to be different from function 0, i.e., it had a different class, vendor ID, or device ID, the flag remained set but we didn't make VPD accessible at all. Flip this around so we only set PCI_DEV_FLAGS_VPD_REF_F0 for functions that are identical to function 0, and allow regular VPD access for any other functions. [bhelgaas: changelog, stable tag] Fixes: 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0") Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Acked-by: Myron Stowe Acked-by: Mark Rustad Signed-off-by: Greg Kroah-Hartman

PCI: Fix devfn for VPD access through function 0

2015-10-22T21:49:22+00:00

commit 9d9240756e63dd87d6cbf5da8b98ceb8f8192b55 upstream. Commit 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0") passes PCI_SLOT(devfn) for the devfn parameter of pci_get_slot(). Generally this works because we're fairly well guaranteed that a PCIe device is at slot address 0, but for the general case, including conventional PCI, it's incorrect. We need to get the slot and then convert it back into a devfn. Fixes: 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0") Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Acked-by: Myron Stowe Acked-by: Mark Rustad Signed-off-by: Greg Kroah-Hartman

PCI: Add dev_flags bit to access VPD through function 0

2015-09-21T17:10:48+00:00

commit 932c435caba8a2ce473a91753bad0173269ef334 upstream. Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through function 0 to provide VPD access on other functions. This is for hardware devices that provide copies of the same VPD capability registers in multiple functions. Because the kernel expects that each function has its own registers, both the locking and the state tracking are affected by VPD accesses to different functions. On such devices for example, if a VPD write is performed on function 0, *any* later attempt to read VPD from any other function of that device will hang. This has to do with how the kernel tracks the expected value of the F bit per function. Concurrent accesses to different functions of the same device can not only hang but also corrupt both read and write VPD data. When hangs occur, typically the error message: vpd r/w failed. This is likely a firmware bug on this device. will be seen. Never set this bit on function 0 or there will be an infinite recursion. Signed-off-by: Mark Rustad Signed-off-by: Bjorn Helgaas Acked-by: Alexander Duyck Signed-off-by: Greg Kroah-Hartman

PCI: Add generic config accessors

2015-01-22T19:59:45+00:00

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: Thierry Reding Signed-off-by: Rob Herring Signed-off-by: Bjorn Helgaas Reviewed-by: Thierry Reding

PCI: Apply _HPX Link Control settings to all devices with a link

2014-11-13T22:43:42+00:00

Previously we applied _HPX type 2 record Link Control register settings only to bridges with a subordinate bus. But it's better to apply them to all devices with a link because if the subordinate bus has not been allocated yet, we won't apply settings to the device. Use pcie_cap_has_lnkctl() to determine whether the device has a Link Control register instead of looking at dev->subordinate. [bhelgaas: changelog] Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration") Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas

PCI: Merge multi-line quoted strings

2014-06-11T02:20:42+00:00

Merge quoted strings that are broken across lines into a single entity. The compiler merges them anyway, but checkpatch complains about it, and merging them makes it easier to grep for strings. No functional change. [bhelgaas: changelog, do the same for everything under drivers/pci] Signed-off-by: Ryan Desfosses Signed-off-by: Bjorn Helgaas

PCI: Fix return value from pci_user_{read,write}_config_*()

2014-05-27T23:10:16+00:00

The PCI user-space config accessors pci_user_{read,write}_config_*() return negative error numbers, which were introduced by commit 34e3207205ef ("PCI: handle positive error codes"). That patch converted all positive error numbers from platform-specific PCI config accessors to -EINVAL, which means the callers don't know anything about the specific cause of the failure. The patch fixes the issue by converting the positive PCIBIOS_* error values to generic negative error numbers with pcibios_err_to_errno(). [bhelgaas: changelog] Signed-off-by: Gavin Shan Signed-off-by: Bjorn Helgaas Acked-by: Greg Thelen

PCI: Remove unused pci_vpd_truncate()

2014-01-13T18:14:43+00:00

My philosophy is unused code is dead code. And dead code is subject to bit rot and is a likely source of bugs. Use it or lose it. This reverts db5679437a2b ("PCI: add interface to set visible size of VPD"), removing this interface: pci_vpd_truncate() [bhelgaas: split to separate patch, also remove prototype from pci.h] Signed-off-by: Stephen Hemminger Signed-off-by: Bjorn Helgaas

PCI: Remove pcie_cap_has_devctl()

2013-08-29T02:51:39+00:00

pcie_cap_has_devctl() does nothing, so remove it. Simplicity over consistency in this case. No functional change. Signed-off-by: Bjorn Helgaas Reviewed-By: Jiang Liu

PCI: Support PCIe Capability Slot registers only for ports with slots

2013-08-29T02:51:39+00:00

Previously we allowed callers to access Slot Capabilities, Status, and Control for Root Ports even if the Root Port did not implement a slot. This seems dubious because the spec only requires these registers if a slot is implemented. It's true that even Root Ports without slots must have *space* for these slot registers, because the Root Capabilities, Status, and Control registers are after the slot registers in the capability. However, for a v1 PCIe Capability, the *semantics* of the slot registers are undefined unless a slot is implemented. Signed-off-by: Bjorn Helgaas Reviewed-By: Jiang Liu