PCI/DOE: Expose DOE features via sysfs

PCIe r6.0 added support for Data Object Exchange (DOE). When DOE is
supported, the DOE Discovery Feature must be implemented per PCIe r6.1, sec
6.30.1.1. DOE

PCI/DOE: Expose DOE features via sysfs

PCIe r6.0 added support for Data Object Exchange (DOE). When DOE is
supported, the DOE Discovery Feature must be implemented per PCIe r6.1, sec
6.30.1.1. DOE allows a requester to obtain information about the other DOE
features supported by the device.

The kernel already queries the DOE features supported and caches the
values. Expose the values in sysfs to allow user space to determine which
DOE features are supported by the PCIe device.

By exposing the information to userspace, tools like lspci can relay the
information to users. By listing all of the supported features we can allow
userspace to parse the list, which might include vendor specific features
as well as yet to be supported features.

As the DOE Discovery feature must always be supported we treat it as a
special named attribute case. This allows the usual PCI attribute_group
handling to correctly create the doe_features directory when registering
pci_doe_sysfs_group (otherwise it doesn't and sysfs_add_file_to_group()
will seg fault).

After this patch is supported you can see something like this when
attaching a DOE device:

$ ls /sys/devices/pci0000:00/0000:00:02.0//doe*
0001:01 0001:02 doe_discovery

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alistair Francis <[email protected]>
[bhelgaas: drop pci_doe_sysfs_init() stub return, make
DEVICE_ATTR_RO(doe_discovery) static]
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>

show more ...

PCI: Add 'reset_subordinate' to reset hierarchy below bridge

The "bus" and "cxl_bus" reset methods reset a device by asserting Secondary
Bus Reset on the bridge leading to the device. These only wo

PCI: Add 'reset_subordinate' to reset hierarchy below bridge

The "bus" and "cxl_bus" reset methods reset a device by asserting Secondary
Bus Reset on the bridge leading to the device. These only work if the
device is the only device below the bridge.

Add a sysfs 'reset_subordinate' attribute on bridges that can assert
Secondary Bus Reset regardless of how many devices are below the bridge.

This resets all the devices below a bridge in a single command, including
the locking and config space save/restore that reset methods normally do.

This may be the only way to reset devices that don't support other reset
methods (ACPI, FLR, PM reset, etc).

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Keith Busch <[email protected]>
[bhelgaas: commit log, add capable(CAP_SYS_ADMIN) check]
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Alex Williamson <[email protected]>
Reviewed-by: Amey Narkhede <[email protected]>

show more ...

PCI/NPEM: Add _DSM PCIe SSD status LED management

The PCIe SSD Status LED Management _DSM defined in PCI Firmware Spec r3.3
sec 4.7 provides a way to manage LEDs via ACPI.

The design is similar to

PCI/NPEM: Add _DSM PCIe SSD status LED management

The PCIe SSD Status LED Management _DSM defined in PCI Firmware Spec r3.3
sec 4.7 provides a way to manage LEDs via ACPI.

The design is similar to NPEM defined in PCIe Base Specification r6.1 sec
6.28:

- Both standards are indication oriented,

- _DSM supported bits correspond to NPEM capability register bits,

- _DSM control bits correspond to NPEM control register bits.

_DSM does not support enclosure-specific indications or the special NPEM
commands NPEM_ENABLE and NPEM_RESET.

_DSM is implemented as a second backend in NPEM driver. The backend used is
logged with info priority. The same sysfs interface is used for both NPEM
and _DSM.

According to spec, _DSM has higher priority, and availability of _DSM in
not limited to devices with NPEM support.

The Dell implementation of DSM uses acpi ipmi, which may not be available
immediately (in fact it may take up to 10s for this interface to be
available). It can determine if DSM is supported (GET_SUPPORTED_STATES_DSM
is working) but it cannot serve GET_STATE_DSM or SET_STATE_DSM commands in
this time.

From userspace application perspective (primarily configured by systemd
service) it is better to have not working but configured interface rather
than have it available after few seconds.

For that reason, npem->active_indications cache is now loaded lazily, i.e.
any GET or SET request want cache to be updated if it is not done yet.

Link: https://lore.kernel.org/r/[email protected]
Suggested-by: Lukas Wunner <[email protected]>
Signed-off-by: Stuart Hayes <[email protected]>
Signed-off-by: Mariusz Tkaczyk <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Stuart Hayes <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Ilpo Järvinen <[email protected]>

show more ...

PCI/NPEM: Add Native PCIe Enclosure Management support

Native PCIe Enclosure Management (NPEM, PCIe r6.1 sec 6.28) allows managing
LEDs in storage enclosures. NPEM is indication oriented and it does

PCI/NPEM: Add Native PCIe Enclosure Management support

Native PCIe Enclosure Management (NPEM, PCIe r6.1 sec 6.28) allows managing
LEDs in storage enclosures. NPEM is indication oriented and it does not
give direct access to LEDs. Although each indication *could* represent an
individual LED, multiple indications could also be represented as a single,
multi-color LED or a single LED blinking in a specific interval. The
specification leaves that open.

Each enabled indication (capability register bit on) is represented as a
ledclass_dev which can be controlled through sysfs. For every ledclass
device only 2 brightness states are allowed: LED_ON (1) or LED_OFF (0).
This corresponds to the NPEM control register (Indication bit on/off).

Ledclass devices appear in sysfs as child devices (subdirectory) of PCI
device which has an NPEM Extended Capability and indication is enabled in
NPEM capability register. For example, these are LEDs created for pcieport
"10000:02:05.0" on my setup:

leds/
├── 10000:02:05.0:enclosure:fail
├── 10000:02:05.0:enclosure:locate
├── 10000:02:05.0:enclosure:ok
└── 10000:02:05.0:enclosure:rebuild

They can be also found in "/sys/class/leds" directory. The parent PCIe
device domain/bus/device/function address is used to guarantee uniqueness
across leds subsystem.

To enable/disable a "fail" indication, the "brightness" file can be edited:

echo 1 > ./leds/10000:02:05.0:enclosure:fail/brightness
echo 0 > ./leds/10000:02:05.0:enclosure:fail/brightness

PCIe r6.1, sec 7.9.19.2 defines the possible indications.

Multiple indications for same parent PCIe device can conflict and hardware
may update them when processing new request. To avoid issues, driver
refresh all indications by reading back control register.

This driver expects to be the exclusive NPEM extended capability manager.
It waits up to 1 second after imposing new request, it doesn't verify if
controller is busy before write, and it assumes the mutex lock gives
protection from concurrent updates.

If _DSM LED management is available, we assume the platform may be using
NPEM for its own purposes (see PCI Firmware Spec r3.3 sec 4.7), so the
driver does not use NPEM. A future patch will add _DSM support; an info
message notes whether NPEM or _DSM is being used.

NPEM is a PCIe extended capability so it should be registered in
pcie_init_capabilities() but it is not possible due to LED dependency. The
parent pci_device must be added earlier for led_classdev_register() to be
successful. NPEM does not require configuration on kernel side, so it is
safe to register LED devices later.

Link: https://lore.kernel.org/r/[email protected]
Suggested-by: Lukas Wunner <[email protected]>
Signed-off-by: Mariusz Tkaczyk <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Stuart Hayes <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Ilpo Järvinen <[email protected]>

show more ...

ABI: sysfs-bus-pci: add documentation for p2pmem allocate

Add documentation for the p2pmem/allocate binary file which allows
for allocating p2pmem buffers in userspace for passing to drivers
that su

ABI: sysfs-bus-pci: add documentation for p2pmem allocate

Add documentation for the p2pmem/allocate binary file which allows
for allocating p2pmem buffers in userspace for passing to drivers
that support them. (Currently only O_DIRECT to NVMe devices.)

Signed-off-by: Logan Gunthorpe <[email protected]>
Reviewed-by: John Hubbard <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Chaitanya Kulkarni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>

show more ...

PCI: Expose PCIe Resizable BAR support via sysfs

Add a simple sysfs interface to Resizable BAR support, largely for the
purposes of assigning such devices to a VM through VFIO. Resizable BARs
prese

PCI: Expose PCIe Resizable BAR support via sysfs

Add a simple sysfs interface to Resizable BAR support, largely for the
purposes of assigning such devices to a VM through VFIO. Resizable BARs
present a difficult feature to expose to a VM through emulation, as
resizing a BAR is done on the host. It can fail, and often does, but we
have no means via emulation of a PCIe REBAR capability to handle the error
cases.

A vfio-pci specific ioctl interface is also cumbersome as there are often
multiple devices within the same bridge aperture and handling them is a
challenge. In the interface proposed here, expanding a BAR potentially
requires such devices to be soft-removed during the resize operation and
rescanned after, in order for all the necessary resources to be released.
A pci-sysfs interface is also more universal than a vfio specific
interface.

Please see the ABI documentation update for usage.

Link: https://lore.kernel.org/r/166336088796.3597940.14973499936692558556.stgit@omen
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Christian König <[email protected]>
Cc: Krzysztof Wilczyński <[email protected]>

show more ...

PCI: Document /sys/bus/pci/devices/.../irq

Document /sys/bus/pci/devices/.../irq.

This file contains the IRQ of the INTx interrupt (or zero if the device
doesn't support INTx interrupts).

If the d

PCI: Document /sys/bus/pci/devices/.../irq

Document /sys/bus/pci/devices/.../irq.

This file contains the IRQ of the INTx interrupt (or zero if the device
doesn't support INTx interrupts).

If the device has enabled MSI (not MSI-X), it contains the first MSI IRQ
instead. This is a historical mistake because devices may support several
MSI or MSI-X vectors, and this file can't contain them all. But we
preserve this behavior to avoid breaking userspace.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Barry Song <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>

show more ...

ABI: sysfs-bus-pci: add a alternative What fields

There are some PCI ABI that aren't shown under:

/sys/bus/pci/drivers/.../

Because they're registered with a different class. That's
the case of,

ABI: sysfs-bus-pci: add a alternative What fields

There are some PCI ABI that aren't shown under:

/sys/bus/pci/drivers/.../

Because they're registered with a different class. That's
the case of, for instance:

/sys/bus/i2c/drivers/CHT Whiskey Cove PMIC/unbind

This one is not present under /sys/bus/pci:

$ find /sys/bus/pci -name 'CHT Whiskey Cove PMIC'

Although clearly this is provided by a PCI driver:

/sys/devices/pci0000:00/0000:00:02.0/i2c-4/subsystem/drivers/CHT Whiskey Cove PMIC/unbind

So, add an altertate What location in order to match bind/unbind
to such devices.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Link: https://lore.kernel.org/r/15ba8c07f1b0fd7359106920c8e34a7b9af7aea6.1632750608.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ABI: sysfs-bus-pci: add documentation for modalias

Even being available since 2005, there's no documentation for
modalias.

Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Mauro Carvalh

ABI: sysfs-bus-pci: add documentation for modalias

Even being available since 2005, there's no documentation for
modalias.

Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Link: https://lore.kernel.org/r/9ceb1fcdbef3c0d2d0368dcc2f19084a3e529ad1.1632750608.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ABI: sysfs-bus-pci: use wildcards on What definitions

An "N" upper letter is not a wildcard, nor can easily be identified
by script, specially since the USB sysfs define things like
bNumInterfaces.

ABI: sysfs-bus-pci: use wildcards on What definitions

An "N" upper letter is not a wildcard, nor can easily be identified
by script, specially since the USB sysfs define things like
bNumInterfaces. Use, instead, <N>, in order to let script/get_abi.pl
to convert it into a Regex.

Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Link: https://lore.kernel.org/r/4ede4ec98e295f054f3e5a6f3f9393b5e3d5d2a7.1631782432.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

PCI: Allow userspace to query and set device reset mechanism

Add "reset_method" sysfs attribute to enable user to query and set
preferred device reset methods and their ordering.

[bhelgaas: on inva

PCI: Allow userspace to query and set device reset mechanism

Add "reset_method" sysfs attribute to enable user to query and set
preferred device reset methods and their ordering.

[bhelgaas: on invalid sysfs input, return error and preserve previous
config, as in earlier patch versions]
Co-developed-by: Alex Williamson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Amey Narkhede <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Raphael Norwitz <[email protected]>

show more ...

docs: typo fixes in Documentation/ABI/

Fix the following typos in the Documentation/ABI/ directory:

- In file obsolete/sysfs-cpuidle, change "obselete" for "obsolete".

- In file removed/sysfs-kern

docs: typo fixes in Documentation/ABI/

Fix the following typos in the Documentation/ABI/ directory:

- In file obsolete/sysfs-cpuidle, change "obselete" for "obsolete".

- In file removed/sysfs-kernel-uids, change "propotional" for "proportional".

- In directory stable/, fix the following words: "associtated" for "associated",
"hexidecimal" for "hexadecimal", "vlue" for "value", "csed" for "caused" and
"wrtie" for "write". This updates a total of five files.

- In directory testing/, fix the following words: "subystem" for "subsystem",
"isochrnous" for "isochronous", "Desctiptors" for "Descriptors", "picutre" for
"picture", "capture" for "capture", "occured" for "ocurred", "connnected" for
"connected","agressively" for "aggressively","manufacturee" for "manufacturer"
and "transaction" for "transaction", "malformatted" for "incorrectly formated"
,"internel" for "internal", "writtento" for "written to", "specificed" for
"specified", "beyound" for "beyond", "Symetric" for "Symmetric". This updates
a total of eleven files.

Signed-off-by: Carlos Bilbao <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Link: https://lore.kernel.org/r/5710038.lOV4Wx5bFT@iron-maiden
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

s390/pci: expose a PCI device's UID as its index

On s390 each PCI device has a user-defined ID (UID) exposed under
/sys/bus/pci/devices/<dev>/uid. This ID was designed to serve as the PCI
device's p

s390/pci: expose a PCI device's UID as its index

On s390 each PCI device has a user-defined ID (UID) exposed under
/sys/bus/pci/devices/<dev>/uid. This ID was designed to serve as the PCI
device's primary index and to match the device within Linux to the
device configured in the hypervisor. To serve as a primary identifier
the UID must be unique within the Linux instance, this is guaranteed by
the platform if and only if the UID Uniqueness Checking flag is set
within the CLP List PCI Functions response.

In this sense the UID serves an analogous function as the SMBIOS
instance number or ACPI index exposed as the "index" respectively
"acpi_index" device attributes and used by e.g. systemd to set interface
names. As s390 does not use and will likely never use ACPI nor SMBIOS
there is no conflict and we can just expose the UID under the "index"
attribute whenever UID Uniqueness Checking is active and get systemd's
interface naming support for free.

Link: https://lore.kernel.org/lkml/[email protected]/
Acked-by: Viktor Mihajlovski <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Acked-by: Narendra K <[email protected]>
Signed-off-by: Niklas Schnelle <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>

show more ...

PCI/IOV: Add sysfs MSI-X vector assignment interface

A typical cloud provider SR-IOV use case is to create many VFs for use by
guest VMs. The VFs may not be assigned to a VM until a customer request

PCI/IOV: Add sysfs MSI-X vector assignment interface

A typical cloud provider SR-IOV use case is to create many VFs for use by
guest VMs. The VFs may not be assigned to a VM until a customer requests a
VM of a certain size, e.g., number of CPUs. A VF may need MSI-X vectors
proportional to the number of CPUs in the VM, but there is no standard way
to change the number of MSI-X vectors supported by a VF.

Some Mellanox ConnectX devices support dynamic assignment of MSI-X vectors
to SR-IOV VFs. This can be done by the PF driver after VFs are enabled,
and it can be done without affecting VFs that are already in use. The
hardware supports a limited pool of MSI-X vectors that can be assigned to
the PF or to individual VFs. This is device-specific behavior that
requires support in the PF driver.

Add a read-only "sriov_vf_total_msix" sysfs file for the PF and a writable
"sriov_vf_msix_count" file for each VF. Management software may use these
to learn how many MSI-X vectors are available and to dynamically assign
them to VFs before the VFs are passed through to a VM.

If the PF driver implements the ->sriov_get_vf_total_msix() callback,
"sriov_vf_total_msix" contains the total number of MSI-X vectors available
for distribution among VFs.

If no driver is bound to the VF, writing "N" to "sriov_vf_msix_count" uses
the PF driver ->sriov_set_msix_vec_count() callback to assign "N" MSI-X
vectors to the VF. When a VF driver subsequently reads the MSI-X Message
Control register, it will see the new Table Size "N".

Link: https://lore.kernel.org/linux-pci/[email protected]
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>

show more ...

PCI: Add sysfs attribute for device power state

While PCI power states D0-D3hot can be queried from user-space via lspci,
D3cold cannot. lspci cannot provide an accurate value when the device is
in

PCI: Add sysfs attribute for device power state

While PCI power states D0-D3hot can be queried from user-space via lspci,
D3cold cannot. lspci cannot provide an accurate value when the device is
in D3cold as it has to restore the device to D0 before it can access its
power state via the configuration space, leading to it reporting D0 or
another on-state. Thus lspci cannot be used to diagnose power consumption
issues for devices that can enter D3cold or to ensure that devices properly
enter D3cold at all.

Add a new sysfs device attribute for the PCI power state, showing the
current power state as seen by the kernel.

[bhelgaas: drop READ_ONCE(), see discussion at the link]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Maximilian Luz <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

docs: ABI: cleanup several ABI documents

There are some ABI documents that, while they don't generate
any warnings, they have issues when parsed by get_abi.pl script
on its output result.

Address t

docs: ABI: cleanup several ABI documents

There are some ABI documents that, while they don't generate
any warnings, they have issues when parsed by get_abi.pl script
on its output result.

Address them, in order to provide a clean output.

Reviewed-by: Tom Rix <[email protected]> # for fpga-manager
Reviewed-By: Kajol Jain<[email protected]> # for sysfs-bus-event_source-devices-hv_gpci and sysfs-bus-event_source-devices-hv_24x7
Acked-by: Jonathan Cameron <[email protected]> #for IIO
Acked-by: Oded Gabbay <[email protected]> # for Habanalabs
Acked-by: Vaibhav Jain <[email protected]> # for sysfs-bus-papr-pmem
Acked-by: Cezary Rojewski <[email protected]> # for catpt
Acked-by: Suzuki K Poulose <[email protected]>
Acked-by: Ilya Dryomov <[email protected]> # for rbd
Acked-by: Jonathan Corbet <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Link: https://lore.kernel.org/r/5bc78e5b68ed1e9e39135173857cb2e753be868f.1604042072.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

PCI/ASPM: Add sysfs attributes for controlling ASPM link states

Add sysfs attributes to Endpoints and other Upstream Ports to control ASPM,
Clock PM, and L1 PM Substates. The new attributes are:

PCI/ASPM: Add sysfs attributes for controlling ASPM link states

Add sysfs attributes to Endpoints and other Upstream Ports to control ASPM,
Clock PM, and L1 PM Substates. The new attributes are:

/sys/devices/pci*/.../link/clkpm
/sys/devices/pci*/.../link/l0s_aspm
/sys/devices/pci*/.../link/l1_aspm
/sys/devices/pci*/.../link/l1_1_aspm
/sys/devices/pci*/.../link/l1_2_aspm
/sys/devices/pci*/.../link/l1_1_pcipm
/sys/devices/pci*/.../link/l1_2_pcipm

An attribute is only visible if both ends of the Link leading to the device
support the state. Writing y/1/on to the file enables the state; n/0/off
disables it.

These attributes can be used to tune the power/performance tradeoff for
individual devices.

[bhelgaas: commit log, rename directory to "link"]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Heiner Kallweit <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI/P2PDMA: Add sysfs group to display p2pmem stats

Add a sysfs group to display statistics about P2P memory that is registered
in each PCI device.

Attributes in the group display the total amount

PCI/P2PDMA: Add sysfs group to display p2pmem stats

Add a sysfs group to display statistics about P2P memory that is registered
in each PCI device.

Attributes in the group display the total amount of P2P memory, the amount
available and whether it is published or not.

Signed-off-by: Logan Gunthorpe <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>

show more ...

PCI: Add sysfs sriov_drivers_autoprobe to control VF driver binding

Sometimes it is not desirable to bind SR-IOV VFs to drivers. This can save
host side resource usage by VF instances that will be

PCI: Add sysfs sriov_drivers_autoprobe to control VF driver binding

Sometimes it is not desirable to bind SR-IOV VFs to drivers. This can save
host side resource usage by VF instances that will be assigned to VMs.

Add a new PCI sysfs interface "sriov_drivers_autoprobe" to control that
from the PF. To modify it, echo 0/n/N (disable probe) or 1/y/Y (enable
probe) to:

/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_drivers_autoprobe

Note that this must be done before enabling VFs. The change will not take
effect if VFs are already enabled. Simply, one can disable VFs by setting
sriov_numvfs to 0, choose whether to probe or not, and then re-enable the
VFs by restoring sriov_numvfs.

[bhelgaas: changelog, ABI doc]
Signed-off-by: Bodong Wang <[email protected]>
Signed-off-by: Eli Cohen <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Reviewed-by: Alex Williamson <[email protected]>

show more ...

Documentation: ABI: testing: sysfs-bus-pci: Fix repetition of word 'the'

The patch replaces 'the the' with 'the' in the documentation.

Signed-off-by: sayli karnik <[email protected]>
Signed

Documentation: ABI: testing: sysfs-bus-pci: Fix repetition of word 'the'

The patch replaces 'the the' with 'the' in the documentation.

Signed-off-by: sayli karnik <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

PCI: Create revision file in sysfs

Currently the revision isn't available via sysfs/libudev thus if one wants
to know the value one needs to read through the config file, which can be
quite time-con

PCI: Create revision file in sysfs

Currently the revision isn't available via sysfs/libudev thus if one wants
to know the value one needs to read through the config file, which can be
quite time-consuming because it wakes/powers up the device.

There are at least two userspace components which could make use the new
file: libpciaccess and libdrm. The former wakes up _every_ PCI device,
which can be observed via glxinfo when using Mesa 10.0+ drivers. The
latter, in association with Mesa 13.0, can lead to 2-3 second delays while
starting firefox, thunderbird or chromium.

Link: https://bugs.freedesktop.org/show_bug.cgi?id=98502
Tested-by: Mauro Santos <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]
CC: Greg KH <[email protected]>

show more ...

PCI: Allow numa_node override via sysfs

NUMA systems with ACPI normally describe the physical topology via _PXM
methods. But many BIOSes don't implement _PXM, which leaves the kernel
with no way to

PCI: Allow numa_node override via sysfs

NUMA systems with ACPI normally describe the physical topology via _PXM
methods. But many BIOSes don't implement _PXM, which leaves the kernel
with no way to discover the device topology, which reduces performance
because we can't put memory and processes close to the device.

The NUMA node of a PCI device is already exported in the sysfs "numa_node"
file. Make that file writable so users can workaround the lack of _PXM
methods in the BIOS. For example:

echo 3 > /sys/devices/pci0000:ff/0000:03:1f.3/numa_node

sets the node for PCI device 0000:03:1f.3.

Writing the file emits a FW_BUG warning to encourage users to request
firmware updates. It also taints the kernel with TAINT_FIRMWARE_WORKAROUND
because overriding the node incorrectly can cause performance issues.

[bhelgaas: changelog, documentation text]
Signed-off-by: Prarit Bhargava <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: Myron Stowe <[email protected]>
CC: Alexander Ducyk <[email protected]>
CC: Jiang Liu <[email protected]>

show more ...

PCI/MSI: Add "msi_bus" sysfs MSI/MSI-X control for endpoints

The "msi_bus" sysfs file for bridges sets a bus flag to allow or disallow
future driver requests for MSI or MSI-X. Previously, the sysfs

PCI/MSI: Add "msi_bus" sysfs MSI/MSI-X control for endpoints

The "msi_bus" sysfs file for bridges sets a bus flag to allow or disallow
future driver requests for MSI or MSI-X. Previously, the sysfs file
existed for endpoints but did nothing.

Add "msi_bus" support for endpoints, so an administrator can prevent the
use of MSI and MSI-X for individual devices.

Note that as for bridges, these changes only affect future driver requests
for MSI or MSI-X, so drivers may need to be reloaded.

Add documentation for the "msi_bus" sysfs file.

[bhelgaas: changelog, comments, add "subordinate", add endpoint printk,
rework bus_flags setting, make bus_flags printk unconditional]
Signed-off-by: Yijing Wang <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Introduce new device binding path using pci_dev.driver_override

The driver_override field allows us to specify the driver for a device
rather than relying on the driver to provide a positive ma

PCI: Introduce new device binding path using pci_dev.driver_override

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 <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>
Reviewed-by: Alexander Graf <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>

show more ...

PCI: Update my email address

Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>