PCI/pwrctrl: Rename pwrctl files to pwrctrl

To slightly reduce confusion between "pwrctl" (the power controller and
power sequencing framework) and "bwctrl" (the bandwidth controller),
rename "pwrct

PCI/pwrctrl: Rename pwrctl files to pwrctrl

To slightly reduce confusion between "pwrctl" (the power controller and
power sequencing framework) and "bwctrl" (the bandwidth controller),
rename "pwrctl" to "pwrctrl" so they use the same "ctrl" suffix.

Rename drivers/pci/pwrctl/ to drivers/pci/pwrctrl/, including the related
MAINTAINERS, include file (include/linux/pci-pwrctl.h), Makefile, and
Kconfig changes.

This is the minimal rename of files only. A subsequent commit will rename
functions and data structures.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Krzysztof Wilczyński <[email protected]>
Acked-by: Krzysztof Wilczyński <[email protected]>

show more ...

PCI: Add TLP Processing Hints (TPH) support

Add support for PCIe TLP Processing Hints (TPH) support (see PCIe r6.2,
sec 6.17).

Add TPH register definitions in pci_regs.h, including the TPH Requeste

PCI: Add TLP Processing Hints (TPH) support

Add support for PCIe TLP Processing Hints (TPH) support (see PCIe r6.2,
sec 6.17).

Add TPH register definitions in pci_regs.h, including the TPH Requester
capability register, TPH Requester control register, TPH Completer
capability, and the ST fields of MSI-X entry.

Introduce pcie_enable_tph() and pcie_disable_tph(), enabling drivers to
toggle TPH support and configure specific ST mode as needed. Also add a new
kernel parameter, "pci=notph", allowing users to disable TPH support across
the entire system.

Link: https://lore.kernel.org/r/[email protected]
Co-developed-by: Jing Liu <[email protected]>
Co-developed-by: Paul Luse <[email protected]>
Co-developed-by: Eric Van Tassell <[email protected]>
Signed-off-by: Jing Liu <[email protected]>
Signed-off-by: Paul Luse <[email protected]>
Signed-off-by: Eric Van Tassell <[email protected]>
Signed-off-by: Wei Huang <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Ajit Khaparde <[email protected]>
Reviewed-by: Somnath Kotur <[email protected]>
Reviewed-by: Andy Gospodarek <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
Reviewed-by: Lukas Wunner <[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 ...

PCI/pwrctl: Add PCI power control core code

Some PCI devices must be powered-on before they can be detected on the
bus. Introduce a simple framework reusing the existing PCI OF
infrastructure.

The

PCI/pwrctl: Add PCI power control core code

Some PCI devices must be powered-on before they can be detected on the
bus. Introduce a simple framework reusing the existing PCI OF
infrastructure.

The way this works is: a DT node representing a PCI device connected to
the port can be matched against its power control platform driver. If
the match succeeds, the driver is responsible for powering-up the device
and calling pci_pwrctl_device_set_ready() which will trigger a PCI bus
rescan as well as subscribe to PCI bus notifications.

When the device is detected and created, we'll make it consume the same
DT node that the platform device did. When the device is bound, we'll
create a device link between it and the parent power control device.

Tested-by: Amit Pundir <[email protected]>
Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD, SM8650-QRD & SM8650-HDK
Tested-by: Caleb Connolly <[email protected]> # OnePlus 8T
Acked-by: Bjorn Helgaas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y

It is possible to enable CONFIG_PCI but disable CONFIG_SYSFS and for
space-constrained devices such as routers, such a configuration may
actuall

PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y

It is possible to enable CONFIG_PCI but disable CONFIG_SYSFS and for
space-constrained devices such as routers, such a configuration may
actually make sense.

However pci-sysfs.c is compiled even if CONFIG_SYSFS is disabled,
unnecessarily increasing the kernel's size.

To rectify that:

* Move pci_mmap_fits() to mmap.c. It is not only needed by
pci-sysfs.c, but also proc.c.

* Move pci_dev_type to probe.c and make it private. It references
pci_dev_attr_groups in pci-sysfs.c. Make that public instead for
consistency with pci_dev_groups, pcibus_groups and pci_bus_groups,
which are likewise public and referenced by struct definitions in
pci-driver.c and probe.c.

* Define pci_dev_groups, pci_dev_attr_groups, pcibus_groups and
pci_bus_groups to NULL if CONFIG_SYSFS is disabled. Provide empty
static inlines for pci_{create,remove}_legacy_files() and
pci_{create,remove}_sysfs_dev_files().

Result:

vmlinux size is reduced by 122996 bytes in my arm 32-bit test build.

Link: https://lore.kernel.org/r/85ca95ae8e4d57ccf082c5c069b8b21eb141846e.1698668982.git.lukas@wunner.de
Signed-off-by: Lukas Wunner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>

show more ...

PCI: Move PCI-specific devres code to drivers/pci/

The pcim_*() functions in lib/devres.c are guarded by an #ifdef CONFIG_PCI
and, thus, don't belong to this file. They are only ever used for PCI an

PCI: Move PCI-specific devres code to drivers/pci/

The pcim_*() functions in lib/devres.c are guarded by an #ifdef CONFIG_PCI
and, thus, don't belong to this file. They are only ever used for PCI and
are not generic infrastructure.

Move all pcim_*() functions in lib/devres.c to drivers/pci/devres.c.
Adjust the Makefile.

Add drivers/pci/devres.c to Documentation.

Link: https://lore.kernel.org/r/[email protected]
Suggested-by: Danilo Krummrich <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Move pci_iomap.c to drivers/pci/

The entirety of pci_iomap.c is guarded by an #ifdef CONFIG_PCI. It,
consequently, does not belong to lib/ because it is not generic
infrastructure.

Move pci_io

PCI: Move pci_iomap.c to drivers/pci/

The entirety of pci_iomap.c is guarded by an #ifdef CONFIG_PCI. It,
consequently, does not belong to lib/ because it is not generic
infrastructure.

Move pci_iomap.c to drivers/pci/ and implement the necessary changes to
Makefiles and Kconfigs.

Update MAINTAINERS file.

Update Documentation.

Link: https://lore.kernel.org/r/[email protected]
[bhelgaas: squash in https://lore.kernel.org/r/[email protected]]
Suggested-by: Danilo Krummrich <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>

show more ...

PCI: Place interrupt related code into irq.c

Interrupt related code is spread into irq.c, pci.c, and setup-irq.c.
Group them into pre-existing irq.c.

Link: https://lore.kernel.org/r/20240129113655.

PCI: Place interrupt related code into irq.c

Interrupt related code is spread into irq.c, pci.c, and setup-irq.c.
Group them into pre-existing irq.c.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Create device tree node for bridge

The PCI endpoint device such as Xilinx Alveo PCI card maps the register
spaces from multiple hardware peripherals to its PCI BAR. Normally,
the PCI core disco

PCI: Create device tree node for bridge

The PCI endpoint device such as Xilinx Alveo PCI card maps the register
spaces from multiple hardware peripherals to its PCI BAR. Normally,
the PCI core discovers devices and BARs using the PCI enumeration process.
There is no infrastructure to discover the hardware peripherals that are
present in a PCI device, and which can be accessed through the PCI BARs.

Apparently, the device tree framework requires a device tree node for the
PCI device. Thus, it can generate the device tree nodes for hardware
peripherals underneath. Because PCI is self discoverable bus, there might
not be a device tree node created for PCI devices. Furthermore, if the PCI
device is hot pluggable, when it is plugged in, the device tree nodes for
its parent bridges are required. Add support to generate device tree node
for PCI bridges.

Add an of_pci_make_dev_node() interface that can be used to create device
tree node for PCI devices.

Add a PCI_DYNAMIC_OF_NODES config option. When the option is turned on,
the kernel will generate device tree nodes for PCI bridges unconditionally.

Initially, add the basic properties for the dynamically generated device
tree nodes which include #address-cells, #size-cells, device_type,
compatible, ranges, reg.

Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Lizhi Hou <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Herring <[email protected]>

show more ...

PCI/DOE: Add DOE mailbox support functions

Introduced in a PCIe r6.0, sec 6.30, DOE provides a config space based
mailbox with standard protocol discovery. Each mailbox is accessed
through a DOE Ex

PCI/DOE: Add DOE mailbox support functions

Introduced in a PCIe r6.0, sec 6.30, DOE provides a config space based
mailbox with standard protocol discovery. Each mailbox is accessed
through a DOE Extended Capability.

Each DOE mailbox must support the DOE discovery protocol in addition to
any number of additional protocols.

Define core PCIe functionality to manage a single PCIe DOE mailbox at a
defined config space offset. Functionality includes iterating,
creating, query of supported protocol, and task submission. Destruction
of the mailboxes is device managed.

Cc: "Li, Ming" <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Co-developed-by: Ira Weiny <[email protected]>
Signed-off-by: Ira Weiny <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dan Williams <[email protected]>

show more ...

PCI/VGA: Move vgaarb to drivers/pci

The VGA arbiter is really PCI-specific and doesn't depend on any GPU
things. Move it to the PCI subsystem.

Note that misc_init() must be called before vga_arb_d

PCI/VGA: Move vgaarb to drivers/pci

The VGA arbiter is really PCI-specific and doesn't depend on any GPU
things. Move it to the PCI subsystem.

Note that misc_init() must be called before vga_arb_device_init(). These
are both subsys_initcalls, so this ordering depends on the link order,
which is determined by drivers/Makefile:

obj-y += pci/
obj-y += char/ <-- misc_init()
obj-y += gpu/ <-- vga_arb_device_init() (before this commit)

The drivers/pci/ subsys_initcalls are called *before* misc_init(), so
convert vga_arb_device_init() to subsys_initcall_sync(), which is called
after *all* subsys_initcalls.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI/MSI: Move code into a separate directory

msi.c is getting larger and really could do with a splitup. Move it into
its own directory to prepare for that.

Signed-off-by: Thomas Gleixner <tglx@lin

PCI/MSI: Move code into a separate directory

msi.c is getting larger and really could do with a splitup. Move it into
its own directory to prepare for that.

Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Juergen Gross <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

PCI: Apply CONFIG_PCI_DEBUG to entire drivers/pci hierarchy

CONFIG_PCI_DEBUG=y adds -DDEBUG to CFLAGS, which enables things like
pr_debug() and dev_dbg() (and hence pci_dbg()). Previously we added

PCI: Apply CONFIG_PCI_DEBUG to entire drivers/pci hierarchy

CONFIG_PCI_DEBUG=y adds -DDEBUG to CFLAGS, which enables things like
pr_debug() and dev_dbg() (and hence pci_dbg()). Previously we added
-DDEBUG for files in drivers/pci/, but not files in subdirectories of
drivers/pci/.

Add -DDEBUG to CFLAGS for all files below drivers/pci/ so CONFIG_PCI_DEBUG
applies to the entire hierarchy.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Junhao He <[email protected]>
Signed-off-by: Yicong Yang <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Krzysztof Wilczyński <[email protected]>

show more ...

PCI/MSI: Move MSI/MSI-X init to msi.c

Move pci_msi_setup_pci_dev(), which disables MSI and MSI-X interrupts, from
probe.c to msi.c so it's with all the other MSI code and more consistent
with other

PCI/MSI: Move MSI/MSI-X init to msi.c

Move pci_msi_setup_pci_dev(), which disables MSI and MSI-X interrupts, from
probe.c to msi.c so it's with all the other MSI code and more consistent
with other capability initialization. This means we must compile msi.c
always, even without CONFIG_PCI_MSI, so wrap the rest of msi.c in an #ifdef
and adjust the Makefile accordingly. No functional change intended.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Thierry Reding <[email protected]>

show more ...

PCI: Allow building PCIe things without PCIEPORTBUS

Some things in drivers/pci/pcie (aspm.c and ptm.c) do not depend on the
PCIe portdrv, so we should be able to build them even if PCIEPORTBUS is no

PCI: Allow building PCIe things without PCIEPORTBUS

Some things in drivers/pci/pcie (aspm.c and ptm.c) do not depend on the
PCIe portdrv, so we should be able to build them even if PCIEPORTBUS is not
selected. Remove the PCIEPORTBUS guard from building pcie/.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Andrew Murray <[email protected]>

show more ...

PCI: OF: Allow of_pci_get_max_link_speed() to be used by PCI Endpoint drivers

of_pci_get_max_link_speed() is built only if CONFIG_PCI is enabled.
Make of_pci_get_max_link_speed() to be also used by

PCI: OF: Allow of_pci_get_max_link_speed() to be used by PCI Endpoint drivers

of_pci_get_max_link_speed() is built only if CONFIG_PCI is enabled.
Make of_pci_get_max_link_speed() to be also used by PCI Endpoint
controllers with just CONFIG_PCI_ENDPOINT enabled.

Signed-off-by: Kishon Vijay Abraham I <[email protected]>
Signed-off-by: Sekhar Nori <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>

show more ...

PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set

We are compiling PCI code today for systems with ACPI and no PCI
device present. Remove the useless code and reduce the tight
dependency.

Sig

PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set

We are compiling PCI code today for systems with ACPI and no PCI
device present. Remove the useless code and reduce the tight
dependency.

Signed-off-by: Sinan Kaya <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]> # PCI parts
Acked-by: Ingo Molnar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

PCI: Introduce PCI bridge emulated config space common logic

Some PCI host controllers do not expose a configuration space for the
root port PCI bridge. Due to this, the Marvell Armada 370/38x/XP PC

PCI: Introduce PCI bridge emulated config space common logic

Some PCI host controllers do not expose a configuration space for the
root port PCI bridge. Due to this, the Marvell Armada 370/38x/XP PCI
controller driver (pci-mvebu) emulates a root port PCI bridge
configuration space, and uses that to (among other things) dynamically
create the memory windows that correspond to the PCI MEM and I/O
regions.

Since we now need to add a very similar logic for the Marvell Armada
37xx PCI controller driver (pci-aardvark), instead of duplicating the
code, we create in this commit a common logic called pci-bridge-emul.

The idea of this logic is to emulate a root port PCI bridge
configuration space by providing configuration space read/write
operations, and faking behind the scenes the configuration space of a
PCI bridge. A PCI host controller driver simply has to call
pci_bridge_emul_conf_read() and pci_bridge_emul_conf_write() to
read/write the configuration space of the bridge.

By default, the PCI bridge configuration space is simply emulated by a
chunk of memory, but the PCI host controller can override the behavior
of the read and write operations on a per-register basis to do
additional actions if needed. We take care of complying with the
behavior of the PCI configuration space registers in terms of bits
that are read-write, read-only, reserved and write-1-to-clear.

Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Russell King <[email protected]>

show more ...

PCI/P2PDMA: Support peer-to-peer memory

Some PCI devices may have memory mapped in a BAR space that's intended for
use in peer-to-peer transactions. To enable such transactions the memory
must be r

PCI/P2PDMA: Support peer-to-peer memory

Some PCI devices may have memory mapped in a BAR space that's intended for
use in peer-to-peer transactions. To enable such transactions the memory
must be registered with ZONE_DEVICE pages so it can be used by DMA
interfaces in existing drivers.

Add an interface for other subsystems to find and allocate chunks of P2P
memory as necessary to facilitate transfers between two PCI peers:

struct pci_dev *pci_p2pmem_find[_many]();
int pci_p2pdma_distance[_many]();
void *pci_alloc_p2pmem();

The new interface requires a driver to collect a list of client devices
involved in the transaction then call pci_p2pmem_find() to obtain any
suitable P2P memory. Alternatively, if the caller knows a device which
provides P2P memory, they can use pci_p2pdma_distance() to determine if it
is usable. With a suitable p2pmem device, memory can then be allocated
with pci_alloc_p2pmem() for use in DMA transactions.

Depending on hardware, using peer-to-peer memory may reduce the bandwidth
of the transfer but can significantly reduce pressure on system memory.
This may be desirable in many cases: for example a system could be designed
with a small CPU connected to a PCIe switch by a small number of lanes
which would maximize the number of lanes available to connect to NVMe
devices.

The code is designed to only utilize the p2pmem device if all the devices
involved in a transfer are behind the same PCI bridge. This is because we
have no way of knowing whether peer-to-peer routing between PCIe Root Ports
is supported (PCIe r4.0, sec 1.3.1). Additionally, the benefits of P2P
transfers that go through the RC is limited to only reducing DRAM usage
and, in some cases, coding convenience. The PCI-SIG may be exploring
adding a new capability bit to advertise whether this is possible for
future hardware.

This commit includes significant rework and feedback from Christoph
Hellwig.

Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Logan Gunthorpe <[email protected]>
[bhelgaas: fold in fix from Keith Busch <[email protected]>:
https://lore.kernel.org/linux-pci/[email protected],
to address comment from Dan Carpenter <[email protected]>, fold in
https://lore.kernel.org/linux-pci/[email protected]]
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Initialize endpoint library before controllers

The endpoint library must be initialized before its users, which are in
drivers/pci/controllers. The endpoint initialization currently depends on

PCI: Initialize endpoint library before controllers

The endpoint library must be initialized before its users, which are in
drivers/pci/controllers. The endpoint initialization currently depends on
link order.

This corrects a kernel crash when loading the Cadence EP driver, since it
calls devm_pci_epc_create() and this is only valid once the endpoint
library has been initialized.

Fixes: 6e0832fa432e ("PCI: Collect all native drivers under drivers/pci/controller/")
Signed-off-by: Alan Douglas <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI: Collect all native drivers under drivers/pci/controller/

Native PCI drivers for root complex devices were originally all in
drivers/pci/host/. Some of these devices can also be operated in end

PCI: Collect all native drivers under drivers/pci/controller/

Native PCI drivers for root complex devices were originally all in
drivers/pci/host/. Some of these devices can also be operated in endpoint
mode. Drivers for endpoint mode didn't seem to fit in the "host"
directory, so we put both the root complex and endpoint drivers in
per-device directories, e.g., drivers/pci/dwc/, drivers/pci/cadence/, etc.

These per-device directories contain trivial Kconfig and Makefiles and
clutter drivers/pci/. Make a new drivers/pci/controllers/ directory and
collect all the device-specific drivers there.

No functional change intended.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Shawn Lin <[email protected]>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

PCI/IOV: Add pci-pf-stub driver for PFs that only enable VFs

Some SR-IOV PF devices provide no functionality other than acting as a
means of enabling VFs. For these devices, we want to enable the V

PCI/IOV: Add pci-pf-stub driver for PFs that only enable VFs

Some SR-IOV PF devices provide no functionality other than acting as a
means of enabling VFs. For these devices, we want to enable the VFs and
assign them to guest virtual machines, but there's no need to have a driver
for the PF itself.

Add a new pci-pf-stub driver to claim those PF devices and provide the
generic VF enable functionality. An administrator can use the sysfs
"sriov_numvfs" file to enable VFs, then assign them to guests.

For now I only have one example ID provided by Amazon in terms of devices
that require this functionality. The general idea is that in the future we
will see other devices added as vendors come up with devices where the PF
is more or less just a lightweight shim used to allocate VFs.

Signed-off-by: Alexander Duyck <[email protected]>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Greg Rose <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>

show more ...

PCI: Tidy Makefiles

Indent things so they line up neatly and remove extra blank lines and
superfluous comments. No functional change intended.

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

PCI: cadence: Add EndPoint Controller driver for Cadence PCIe controller

This patch adds support to the Cadence PCIe controller in endpoint mode.

Since pieces of source code are shared with the hos

PCI: cadence: Add EndPoint Controller driver for Cadence PCIe controller

This patch adds support to the Cadence PCIe controller in endpoint mode.

Since pieces of source code are shared with the host driver (Root
Complex mode), we create a new directory under drivers/pci dedicated to
the Cadence PCIe controller. The common code is placed into
drivers/pci/cadence/pcie-cadence.c and used by both the host and
endpoint controller drivers.

Signed-off-by: Cyrille Pitchen <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>

show more ...

PCI: Regroup all PCI related entries into drivers/pci/Makefile

Clean up drivers/Makefile by moving the pci/endpoint and pci/dwc entries
from drivers/Makefile into drivers/pci/Makefile.

Since we don

PCI: Regroup all PCI related entries into drivers/pci/Makefile

Clean up drivers/Makefile by moving the pci/endpoint and pci/dwc entries
from drivers/Makefile into drivers/pci/Makefile.

Since we don't want to introduce any dependency between CONFIG_PCI and
CONFIG_PCI_ENDPOINT, we now always execute drivers/pci/Makefile.

Hence all Makefiles in drivers/pci/ were updated accordingly so no file is
compiled when CONFIG_PCI is not defined.

Also, we add a comment to reinforce that EPC and EPF libraries must be
initialized before their users. Hence built-in EPC drivers, such as
those of Designware, are linked after the endpoint core libraries.

Finally, we add another comment to explain why obj-y has been chosen
instead of obj-$(CONFIG_PCIE_DW) to parse the dwc/ sub-folder.

Signed-off-by: Cyrille Pitchen <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>

show more ...