| Age | Commit message (Collapse) | Author |
|---|
|
In the Keystone controller driver, change all names using "legacy" to
use "intx" instead, to match the term used in the PCI specifications.
Given that the field legacy_intc_np of struct keystone_pcie is unused,
this field is removed instead of being renamed.
Link: https://lore.kernel.org/r/20231122060406.14695-11-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
|
|
Rename the function dw_pcie_ep_raise_legacy_irq() of the Designware
endpoint controller driver to dw_pcie_ep_raise_intx_irq() to match the
name of the PCI_IRQ_INTX macro.
Link: https://lore.kernel.org/r/20231122060406.14695-10-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
|
|
In the Cadence endpoint controller driver, rename the function
cdns_pcie_ep_send_legacy_irq() to cdns_pcie_ep_send_intx_irq() to match
the macro PCI_IRQ_INTX name. Related comments and messages mentioning
"legacy" are also changed to refer to "intx".
Link: https://lore.kernel.org/r/20231122060406.14695-9-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
|
|
Rename the function dra7xx_pcie_raise_legacy_irq() to
dra7xx_pcie_raise_intx_irq() to match the use of the PCI_IRQ_INTX macro.
Link: https://lore.kernel.org/r/20231122060406.14695-8-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
|
|
The pci_epf_ops struct for the PCI endpoint test driver is never modified.
Mark it as const so it can be placed in the read-only section.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20230722230848.589428-5-lars@metafoo.de
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
|
|
The pci_epf_ops struct for the PCI endpoint vNTB driver is never modified.
Mark it as const so it can be placed in the read-only section.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20230722230848.589428-4-lars@metafoo.de
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
|
|
The pci_epf_ops struct for the PCI endpoint NTB driver is never modified.
Mark it as const so it can be placed in the read-only section.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20230722230848.589428-3-lars@metafoo.de
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
|
|
Both the pci_epf_ops and pci_epf_evnt_ops structs for the PCI endpoint
MHI driver are never modified.
Mark them as const so they can be placed in the read-only section.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20230722230848.589428-2-lars@metafoo.de
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
|
|
The pci_epf_ops struct contains a set of callbacks that are used by the
pci_epf_driver, and is never modified by the EPF core itself.
Marking the struct pointer const allows EPF drivers to declare their
pci_epf_ops struct to be const.
This allows the struct to be placed in the read-only section. Which
for example brings some security benefits as the callbacks can not be
overwritten.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20230722230848.589428-1-lars@metafoo.de
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
|
|
In the root complex pci endpoint test function driver, change macros and
functions names using the term "legacy" to use "intx" instead to
match the term used in the PCI specifications.
Link: https://lore.kernel.org/r/20231122060406.14695-6-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
|
|
In the endpoint test function driver, rename IRQ_TYPE_LEGACY to
IRQ_TYPE_INTX and COMMAND_RAISE_LEGACY_IRQ to COMMAND_RAISE_INTX_IRQ
to match the term used in the PCI specifications.
Link: https://lore.kernel.org/r/20231122060406.14695-5-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
|
|
In the endpoint controller core code, change references to "legacy"
interrupts to "INTX" interrupts to match the term used in the PCI
specifications.
Link: https://lore.kernel.org/r/20231122060406.14695-4-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
|
|
linux/pci.h defines the IRQ flags PCI_IRQ_INTX, PCI_IRQ_MSI and
PCI_IRQ_MSIX. Let's use these flags directly instead of the endpoint
definitions provided by enum pci_epc_irq_type. This removes the need
for defining this enum type completely.
Link: https://lore.kernel.org/r/20231122060406.14695-3-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
|
Rename PCI_IRQ_LEGACY to PCI_IRQ_INTX to be more explicit about the type
of IRQ being referenced as well as to match the PCI specifications
terms. Redefine PCI_IRQ_LEGACY as an alias to PCI_IRQ_INTX to avoid the
need for doing the renaming tree-wide. New drivers and new code should
now prefer using PCI_IRQ_INTX instead of PCI_IRQ_LEGACY.
Link: https://lore.kernel.org/r/20231122060406.14695-2-dlemoal@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
|
There is no need to call the dev_err() function directly to print a
custom message when handling an error from either the platform_get_irq()
or platform_get_irq_byname() functions as both are going to display an
appropriate error message in case of a failure.
./drivers/pci/controller/pcie-xilinx-dma-pl.c:688:2-9: line 688 is redundant because platform_get_irq() already prints an error
./drivers/pci/controller/pcie-xilinx-dma-pl.c:702:2-9: line 702 is redundant because platform_get_irq() already prints an error
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7074
Link: https://lore.kernel.org/linux-pci/20231030061242.51475-1-yang.lee@linux.alibaba.com
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
Commit 6f5e193bfb55 ("PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get
correct MSI-X table address") modified dw_pcie_ep_raise_msix_irq() to
support iATUs which require a specific alignment.
However, this support cannot have been properly tested.
The whole point is for the iATU to map an address that is aligned,
using dw_pcie_ep_map_addr(), and then let the writel() write to
ep->msi_mem + aligned_offset.
Thus, modify the address that is mapped such that it is aligned.
With this change, dw_pcie_ep_raise_msix_irq() matches the logic in
dw_pcie_ep_raise_msi_irq().
Link: https://lore.kernel.org/linux-pci/20231128132231.2221614-1-nks@flawful.org
Fixes: 6f5e193bfb55 ("PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table address")
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: stable@vger.kernel.org # 5.7
Cc: Kishon Vijay Abraham I <kishon@kernel.org>
|
|
Use devm_kasprintf() instead of open coding it. This saves the need of
an intermediate buffer.
There was also no reason to use devm_kstrdup_const() as string is known
to be constant.
[kwilczynski: commit log, and add missing Reviewed-by tag]
Link: https://lore.kernel.org/linux-pci/1bad6879083a7d836c8a47418a0afa22485e8f69.1700294127.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Link: https://lore.kernel.org/linux-pci/c3a51791d54deaa818b8526975fc4e16ef1090ce.1701682617.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Link: https://lore.kernel.org/linux-pci/06612aff79dfb52d5b0b20129dff5e4b1f04d3a7.1701682617.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Link: https://lore.kernel.org/linux-pci/50de44ea8931465fd9cdc821854ea761cb43adf6.1701682617.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
As part of converting RISC-V SOC_FOO symbols to ARCH_FOO to match the
use of such symbols on other architectures, convert the SiFive PCI
drivers to use the newer symbol.
Link: https://lore.kernel.org/linux-pci/20230918-safeness-cornflake-62278bc3aaaa@wendy
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
Log bridge secondary/subordinate bus and window information at the same
time we log the bridge BARs, just after discovering the bridge and before
scanning the bridge's secondary bus. This logs the bridge and downstream
devices in a more logical order:
- pci 0000:00:01.0: [8086:1901] type 01 class 0x060400
- pci 0000:01:00.0: [10de:13b6] type 00 class 0x030200
- pci 0000:01:00.0: reg 0x10: [mem 0xec000000-0xecffffff]
- pci 0000:00:01.0: PCI bridge to [bus 01]
- pci 0000:00:01.0: bridge window [io 0xe000-0xefff]
+ pci 0000:00:01.0: [8086:1901] type 01 class 0x060400
+ pci 0000:00:01.0: PCI bridge to [bus 01]
+ pci 0000:00:01.0: bridge window [io 0xe000-0xefff]
+ pci 0000:01:00.0: [10de:13b6] type 00 class 0x030200
+ pci 0000:01:00.0: reg 0x10: [mem 0xec000000-0xecffffff]
Note that we read the windows into a temporary struct resource that is
thrown away, not into the resources in the struct pci_bus.
The windows may be adjusted after we know what downstream devices require,
and those adjustments are logged as they are made.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Previously pci_read_bridge_io(), pci_read_bridge_mmio(), and
pci_read_bridge_mmio_pref() unconditionally logged the bridge window
resource. A future change will call these functions earlier and more
often. Add a "log" parameter so callers can control whether to generate
the log message. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Previously we logged information about devices *below* the bridge before
logging information about the bridge itself, e.g.,
pci 0000:00:01.0: [8086:1901] type 01 class 0x060400
pci 0000:01:00.0: [10de:13b6] type 00 class 0x030200
pci 0000:01:00.0: reg 0x10: [mem 0xec000000-0xecffffff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0: bridge window [io 0xe000-0xefff]
This is partly because the bridge windows are read in this path:
pci_scan_child_bus_extend
for (devfn = 0; devfn < 256; devfn += 8)
pci_scan_slot(bus, devfn) # scan below bridge
pcibios_fixup_bus(bus)
pci_read_bridge_bases(bus) # read bridge windows
pci_read_bridge_io(bus)
Remove the assumption that the secondary (child) pci_bus already exists by
passing in the bridge device (instead of the pci_bus) and a resource
pointer when reading bridge windows. A future change can use this to log
the bridge details before we enumerate the devices below the bridge.
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Move pci_read_bridge_windows() below the functions that read the I/O,
memory, and prefetchable memory windows, so pci_read_bridge_windows() can
use them in the future. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Use the pci_resource_name() to get the name of the resource and use it
while printing log messages.
[bhelgaas: rename to match struct resource * names, also use names in other
BAR messages]
Link: https://lore.kernel.org/r/20211106112606.192563-3-puranjay12@gmail.com
Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The PCI log messages print the register offsets at some places and BAR
numbers at other places. There is no uniformity in this logging mechanism.
It would be better to print names than register offsets.
Add a helper function that aids in printing more meaningful information
about the BAR numbers like "VF BAR", "ROM", "bridge window", etc. This
function can be called while printing PCI log messages.
[bhelgaas: fold in Lukas' static array suggestion from
https://lore.kernel.org/all/20211106115831.GA7452@wunner.de/]
Link: https://lore.kernel.org/r/20211106112606.192563-2-puranjay12@gmail.com
Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Log the device type when enumeration a device. Sample output changes:
- pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
+ pci 0000:00:00.0: [8086:1237] type 00 class 0x060000 conventional PCI endpoint
- pci 0000:00:1c.0: [8086:a110] type 01 class 0x060400
+ pci 0000:00:1c.0: [8086:a110] type 01 class 0x060400 PCIe Root Port
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The KingFisher board has regulators for miniPCIe, so enable these
optional regulators using devm. devm will automatically disable them
when the driver releases the device. Order variables in reverse-xmas
while we are here.
[kwilczynski: update style to match rest of the code]
Link: https://lore.kernel.org/linux-pci/20231105092908.3792-3-wsa+renesas@sang-engineering.com
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
|
|
Support regulators found on the KingFisher board for miniPCIe (1.5 and
3.3v). For completeness, describe a 12v regulator while we are here.
Link: https://lore.kernel.org/linux-pci/20231105092908.3792-2-wsa+renesas@sang-engineering.com
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform
bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h.
As a result, there's a pretty much random mix of those include files
used throughout the tree. In order to detangle these headers and replace
the implicit includes with struct declarations, users need to explicitly
include the correct includes.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20231207165251.2855783-1-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
|
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
This is less verbose.
Link: https://lore.kernel.org/linux-pci/270f25cdc154f3b0309e57b2f6421776752e2170.1702230593.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
Add support for setting of two-bit field that allows selection of 4x lane
PCIe which was previously limited to only 2x lanes.
Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-5-s-vadapalli@ti.com
Signed-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
|
|
Various platforms have different maximum amount of lanes that can be
selected. Add max_lanes to struct j721e_pcie to allow for detection of this
which is needed to calculate the needed bitmask size for the possible lane
count.
Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-4-s-vadapalli@ti.com
Signed-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
Add definition for j784s4-pci-ep and j784s4-pci-host devices along with
schema checks for num-lanes.
Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-3-s-vadapalli@ti.com
Signed-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
Add num-lanes schema checks based on compatible string on available lanes
for that platform.
Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-2-s-vadapalli@ti.com
Signed-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
Add suspend/resume support for Layerscape LS1043a.
In the suspend path, PME_Turn_Off message is sent to the endpoint to
transition the link to L2/L3_Ready state. In this SoC, there is no way to
check if the controller has received the PME_To_Ack from the endpoint or
not. So to be on the safer side, the driver just waits for
PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF
bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3
state depending on the VAUX supply.
In the resume path, the link is brought back from L2 to L0 by doing a
software reset.
Link: https://lore.kernel.org/r/20231204160829.2498703-5-Frank.Li@nxp.com
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: Roy Zang <Roy.Zang@nxp.com>
|
|
'pf' and 'lut' are two different acronyms describing the same
thing, basically it is a MMIO base address plus an offset.
Rename them to avoid duplicate pf_* and lut_* naming schemes in the
driver.
Link: https://lore.kernel.org/r/20231204160829.2498703-4-Frank.Li@nxp.com
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: Roy Zang <Roy.Zang@nxp.com>
|
|
Add suspend/resume support for Layerscape LS1021a.
In the suspend path, PME_Turn_Off message is sent to the endpoint to
transition the link to L2/L3_Ready state. In this SoC, there is no way to
check if the controller has received the PME_To_Ack from the endpoint or
not. So to be on the safer side, the driver just waits for
PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF
bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3
state depending on the VAUX supply.
In the resume path, the link is brought back from L2 to L0 by doing a
software reset.
Link: https://lore.kernel.org/r/20231204160829.2498703-3-Frank.Li@nxp.com
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: Roy Zang <Roy.Zang@nxp.com>
|
|
Since different SoCs require different sequences for exiting L2, let's add
a separate "exit_from_l2()" callback to handle SoC specific sequences.
Change ls_pcie_exit_from_l2() return value from void to int in order
to propagate errors. Return an error if the exit_from_l2() callback
fails in the resume flow.
Link: https://lore.kernel.org/r/20231204160829.2498703-2-Frank.Li@nxp.com
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: Roy Zang <Roy.Zang@nxp.com>
|
|
Add more Root Port Device IDs to pci_quirk_zhaoxin_pcie_ports_acs() for
some new Zhaoxin platforms.
Fixes: 299bd044a6f3 ("PCI: Add ACS quirk for Zhaoxin Root/Downstream Ports")
Link: https://lore.kernel.org/r/20231211091543.735903-1-LeoLiu-oc@zhaoxin.com
Signed-off-by: LeoLiuoc <LeoLiu-oc@zhaoxin.com>
[bhelgaas: update subject, drop changelog, add Fixes, add stable tag, fix
whitespace, wrap code comment]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: <stable@vger.kernel.org> # 5.7
|
|
The typical style is to define functions before calling them. Move
pci_mmcfg_arch_map() and pci_mmcfg_arch_unmap() earlier so they're defined
before they're called. No functional change intended.
Link: https://lore.kernel.org/r/20231121183643.249006-10-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
If pci_mmconfig_alloc() fails, return the failure early so it's obvious
that the failure is the exception, and the success is the normal case. No
functional change intended.
Link: https://lore.kernel.org/r/20231121183643.249006-9-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
In pci_mmconfig_insert(), there's no reference to "addr" between locking
pci_mmcfg_lock and testing "addr", so it *looks* like we should move the
test before the lock.
But 07f9b61c3915 ("x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at
address zero") did that, which broke things by returning -EINVAL when
"addr" is zero instead of -EEXIST.
So 07f9b61c3915 was reverted by 67d470e0e171 ("Revert "x86/PCI: MMCONFIG:
Check earlier for MMCONFIG region at address zero"").
Add a comment about this issue to prevent it from happening again.
Link: https://lore.kernel.org/r/20231121183643.249006-8-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
"pci_mmcfg_check_reserved()" doesn't give a hint about what the boolean
return value means. Rename it to pci_mmcfg_reserved() so testing
"if (pci_mmcfg_reserved())" makes sense.
Update callers to treat the return value as boolean instead of comparing
with 0.
Link: https://lore.kernel.org/r/20231121183643.249006-7-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
"acpi_mcfg_check_entry()" doesn't give a hint about what the return value
means. Rename it to "acpi_mcfg_valid_entry()", convert the return value to
bool, and update the return values and callers to match so testing
"if (acpi_mcfg_valid_entry())" makes sense.
Link: https://lore.kernel.org/r/20231121183643.249006-6-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The "MMCONFIG" term is not used in PCI/PCIe specs. Replace it with "ECAM",
the term used in PCIe r6.0, sec 7.2.2.
Define pr_fmt() instead of repeating PREFIX in every log message.
Link: https://lore.kernel.org/r/20231121183643.249006-5-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
MCFG handling is a frequent source of problems. Add more logging to aid in
debugging.
Enable the logging with CONFIG_DYNAMIC_DEBUG=y and the kernel boot
parameter 'dyndbg="file arch/x86/pci +p"'.
Link: https://lore.kernel.org/r/20231121183643.249006-4-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
fd3a8cff4d4a ("x86/pci: Treat EfiMemoryMappedIO as reservation of ECAM
space") added the concept of using the EFI memory map to help decide
whether ECAM space mentioned in the MCFG table is valid.
Unfortunately it described that EfiMemoryMappedIO space as "reserved", but
it is actually not *reserved* by the EFI memory map. EfiMemoryMappedIO
only means the firmware requested that the OS map this space for use by
firmware runtime services.
Change the dmesg logging to describe it as simply "EfiMemoryMappedIO", not
as "reserved as EfiMemoryMappedIO". A previous commit actually *does*
reserve the space if ACPI PNP0C01/02 devices haven't done so:
- PCI: ECAM at [mem 0xe0000000-0xefffffff] reserved as EfiMemoryMappedIO
+ PCI: ECAM at [mem 0xe0000000-0xefffffff] is EfiMemoryMappedIO; assuming valid
PCI: ECAM [mem 0xe0000000-0xefffffff] reserved to work around lack of ACPI motherboard _CRS
Link: https://lore.kernel.org/r/20231121183643.249006-3-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Tomasz, Sebastian, and some Proxmox users reported problems initializing
ixgbe NICs.
I think the problem is that ECAM space described in the ACPI MCFG table is
not reserved via a PNP0C02 _CRS method as required by the PCI Firmware spec
(r3.3, sec 4.1.2), but it *is* included in the PNP0A03 host bridge _CRS as
part of the MMIO aperture.
If we allocate space for a PCI BAR, we're likely to allocate it from that
ECAM space, which obviously cannot work.
This could happen for any device, but in the ixgbe case it happens because
it's an SR-IOV device and the BIOS didn't allocate space for the VF BARs,
so Linux reallocated the bridge window leading to ixgbe and put it on top
of the ECAM space. From Tomasz' system:
PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000)
PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] not reserved in ACPI motherboard resources
pci_bus 0000:00: root bus resource [mem 0x80000000-0xfbffffff window]
pci 0000:00:01.1: PCI bridge to [bus 02-03]
pci 0000:00:01.1: bridge window [mem 0xfb900000-0xfbbfffff]
pci 0000:02:00.0: [8086:10fb] type 00 class 0x020000 # ixgbe
pci 0000:02:00.0: reg 0x10: [mem 0xfba80000-0xfbafffff 64bit]
pci 0000:02:00.0: VF(n) BAR0 space: [mem 0x00000000-0x000fffff 64bit] (contains BAR0 for 64 VFs)
pci 0000:02:00.0: BAR 7: no space for [mem size 0x00100000 64bit] # VF BAR 0
pci_bus 0000:00: No. 2 try to assign unassigned res
pci 0000:00:01.1: resource 14 [mem 0xfb900000-0xfbbfffff] released
pci 0000:00:01.1: BAR 14: assigned [mem 0x80000000-0x806fffff]
pci 0000:02:00.0: BAR 0: assigned [mem 0x80000000-0x8007ffff 64bit]
pci 0000:02:00.0: BAR 7: assigned [mem 0x80204000-0x80303fff 64bit] # VF BAR 0
Fixes: 07eab0901ede ("efi/x86: Remove EfiMemoryMappedIO from E820 map")
Fixes: fd3a8cff4d4a ("x86/pci: Treat EfiMemoryMappedIO as reservation of ECAM space")
Reported-by: Tomasz Pala <gotar@polanet.pl>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218050
Reported-by: Sebastian Manciulea <manciuleas@protonmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218107
Link: https://forum.proxmox.com/threads/proxmox-8-kernel-6-2-16-4-pve-ixgbe-driver-fails-to-load-due-to-pci-device-probing-failure.131203/
Link: https://lore.kernel.org/r/20231121183643.249006-2-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # v6.2+
|
