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

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

2013-11-29T18:42:15Z

commit 6d3a1741f1e648cfbd5a0cc94477a0d5004c6f5e upstream. 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 Acked-by: Myron Stowe Signed-off-by: Greg Kroah-Hartman

PCI: Remove PCIe Capability version checks

2013-11-29T18:42:15Z

commit c8b303d0206b28c4ff3aecada47108d1655ae00f upstream. Previously we relied on the PCIe r3.0, sec 7.8, spec language that says "For Functions that do not implement the [Link, Slot, Root] registers, these spaces must be hardwired to 0b," which means that for v2 PCIe capabilities, we don't need to check the device type at all. But it's simpler if we don't need to check the capability version at all, and I think the spec is explicit enough about which registers are required for which types that we can remove the version checks. Signed-off-by: Bjorn Helgaas Reviewed-By: Jiang Liu Acked-by: Myron Stowe Signed-off-by: Greg Kroah-Hartman

PCI: Allow PCIe Capability link-related register access for switches

2013-11-29T18:42:15Z

commit d3694d4fa3f44f6a295f8ab064937c8a1549d174 upstream. Every PCIe device has a link, except Root Complex Integrated Endpoints and Root Complex Event Collectors. Previously we didn't give access to PCIe capability link-related registers for Upstream Ports, Downstream Ports, and Bridges, so attempts to read PCI_EXP_LNKCTL incorrectly returned zero. See PCIe spec r3.0, sec 7.8 and 1.3.2.3. Reference: http://lkml.kernel.org/r/979A8436335E3744ADCD3A9F2A2B68A52AD136BE@SJEXCHMB10.corp.ad.broadcom.com Reported-by: Yuval Mintz Signed-off-by: Bjorn Helgaas Reviewed-By: Jiang Liu Signed-off-by: Greg Kroah-Hartman

PCI: Fix PCI Express Capability accessors for PCI_EXP_FLAGS

2013-02-15T18:46:24Z

PCI_EXP_FLAGS_TYPE is a mask, not an offset. Fix it. Previously, pcie_capability_read_word(..., PCI_EXP_FLAGS, ...) would fail. [bhelgaas: tweak changelog] Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.7+

PCI: Use PCI Express Capability accessor

2013-01-31T04:24:39Z

Use PCI Express Capability access functions to simplify device Capabilities Register usages. Signed-off-by: Myron Stowe Signed-off-by: Bjorn Helgaas

PCI: Add accessors for PCI Express Capability

2012-08-23T15:41:20Z

The PCI Express Capability (PCIe spec r3.0, sec 7.8) comes in two versions, v1 and v2. In v1 Capability structures (PCIe spec r1.0 and r1.1), some fields are optional, so the structure size depends on the device type. This patch adds functions to access this capability so drivers don't have to be aware of the differences between v1 and v2. Note that these new functions apply only to the "PCI Express Capability," not to any of the other "PCI Express Extended Capabilities" (AER, VC, ACS, MFVC, etc.) Function pcie_capability_read_word/dword() reads the PCIe Capabilities register and returns the value in the reference parameter "val". If the PCIe Capabilities register is not implemented on the PCIe device, "val" is set to 0. Function pcie_capability_write_word/dword() writes the value to the specified PCIe Capability register. Function pcie_capability_clear_and_set_word/dword() sets and/or clears bits of a PCIe Capability register. [bhelgaas: changelog, drop "pci_" prefixes, don't export pcie_capability_reg_implemented()] Signed-off-by: Jiang Liu Signed-off-by: Yijing Wang Signed-off-by: Bjorn Helgaas

PCI: export pci_user functions for use by other drivers

2012-06-12T15:21:42Z

VFIO PCI support will make use of these for user-initiated PCI config accesses. Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas

PCI: Introduce INTx check & mask API

2012-01-06T20:10:34Z

These new PCI services allow to probe for 2.3-compliant INTx masking support and then use the feature from PCI interrupt handlers. The services are properly synchronized with concurrent config space access via sysfs or on device reset. This enables generic PCI device drivers like uio_pci_generic or KVM's device assignment to implement the necessary kernel-side IRQ handling without any knowledge about device-specific interrupt status and control registers. Acked-by: Michael S. Tsirkin Signed-off-by: Jan Kiszka Signed-off-by: Jesse Barnes

PCI: Rework config space blocking services

2012-01-06T20:10:33Z

pci_block_user_cfg_access was designed for the use case that a single context, the IPR driver, temporarily delays user space accesses to the config space via sysfs. This assumption became invalid by the time pci_dev_reset was added as locking instance. Today, if you run two loops in parallel that reset the same device via sysfs, you end up with a kernel BUG as pci_block_user_cfg_access detect the broken assumption. This reworks the pci_block_user_cfg_access to a sleeping service pci_cfg_access_lock and an atomic-compatible variant called pci_cfg_access_trylock. The former not only blocks user space access as before but also waits if access was already locked. The latter service just returns false in this case, allowing the caller to resolve the conflict instead of raising a BUG. Adaptions of the ipr driver were originally written by Brian King. Acked-by: Brian King Acked-by: Michael S. Tsirkin Signed-off-by: Jan Kiszka Signed-off-by: Jesse Barnes

PCI: handle positive error codes

2011-05-10T22:43:36Z

Callers expect pci_user_{read,write}_config_*() to indicate errors by returning negative values. Prior to this change, the indicated routines could return positive error codes (e.g. PCIBIOS_BAD_REGISTER_NUMBER) which callers would mistakenly interpret as success. This change converts any non-zero return from the mentioned routines into unambiguous negative value return codes. Signed-off-by: Greg Thelen Signed-off-by: Jesse Barnes