linux.git/drivers/pci/access.c, branch v3.13

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

PCI: Remove PCIe Capability version checks

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

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

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

2013-08-28T17:28:22+00:00

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

PCI: Fix PCI Express Capability accessors for PCI_EXP_FLAGS

2013-02-15T18:46:24+00:00

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:39+00:00

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:20+00:00

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:42+00:00

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:34+00:00

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:33+00:00

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