| Age | Commit message (Collapse) | Author |
|---|
|
- Ioremap() msg_res region using res->start (the CPU address), not the ATU
'cpu_addr', which will be replaced with the ATU input address (which may
not be the CPU address) (Frank Li)
- Rename struct dw_pcie_ob_atu_cfg.cpu_addr to 'parent_bus_addr' (Frank Li)
- Call devm_pci_alloc_host_bridge() early in dw_pcie_host_init() to keep
devicetree-related code together (Frank Li)
- Consolidate devicetree handling in dw_pcie_host_get_resources() (Bjorn
Helgaas)
- Add dw_pcie_parent_bus_offset() to look up the parent bus address of a
specified 'reg' property and return the offset from the CPU physical
address (Frank Li)
- Add cross-checking with .cpu_addr_fixup() and debug logging to
dw_pcie_parent_bus_offset() (Frank Li)
- Use devicetree 'reg[config]' via dw_pcie_parent_bus_offset() to derive
CPU -> ATU addr offset for host controller (Frank Li)
- Call epc_create() early in dw_pcie_ep_init() to keep devicetree-related
code together (Bjorn Helgaas)
- Consolidate devicetree handling in dw_pcie_ep_get_resources() (Bjorn
Helgaas)
- Use devicetree 'reg[addr_space]' via dw_pcie_parent_bus_offset() to
derive CPU -> ATU addr offset for endpoint controller (Frank Li)
- Update dw_pcie_find_index() to remove assumption that ATU input address
is non-zero (Frank Li)
- Apply struct dw_pcie.parent_bus_offset in ATU users to remove use of
.cpu_addr_fixup() when programming ATU (Frank Li)
- Remove imx_pcie_cpu_addr_fixup() since dwc core can now derive the ATU
input address (using parent_bus_offset) from devicetree (Frank Li)
- Remove intel_pcie_cpu_addr() since dwc core can now derive the ATU input
address (using parent_bus_offset) from devicetree (Frank Li)
* pci/controller/dwc-cpu-addr-fixup:
PCI: intel-gw: Remove intel_pcie_cpu_addr()
PCI: imx6: Remove imx_pcie_cpu_addr_fixup()
PCI: dwc: Use parent_bus_offset to remove need for .cpu_addr_fixup()
PCI: dwc: ep: Ensure proper iteration over outbound map windows
PCI: dwc: ep: Use devicetree 'reg[addr_space]' to derive CPU -> ATU addr offset
PCI: dwc: ep: Consolidate devicetree handling in dw_pcie_ep_get_resources()
PCI: dwc: ep: Call epc_create() early in dw_pcie_ep_init()
PCI: dwc: Use devicetree 'reg[config]' to derive CPU -> ATU addr offset
PCI: dwc: Add dw_pcie_parent_bus_offset() checking and debug
PCI: dwc: Add dw_pcie_parent_bus_offset()
PCI: dwc: Consolidate devicetree handling in dw_pcie_host_get_resources()
PCI: dwc: Call devm_pci_alloc_host_bridge() early in dw_pcie_host_init()
PCI: dwc: Rename cpu_addr to parent_bus_addr for ATU configuration
PCI: dwc: Use resource start as ioremap() input in dw_pcie_pme_turn_off()
# Conflicts:
# drivers/pci/controller/dwc/pcie-designware.c
# drivers/pci/controller/dwc/pcie-designware.h
|
|
- Move struct dwc_pcie_vsec_id to include/linux/pcie-dwc.h, where it can be
shared by debugfs, perf, sysfs, etc (Manivannan Sadhasivam)
- Add dw_pcie_find_vsec_capability() to locate Vendor Specific Extended
Capabilities (Shradha Todi)
- Add debugfs-based Silicon Debug, Error Injection, Statistical Counter
support for DWC (Shradha Todi)
- Add debugfs property to expose LTSSM status of DWC PCIe link (Hans Zhang)
- Add Rockchip Vendor ID and Vendor Specific ID of RAS DES Capability so
the DWC debugfs features work for Rockchip as well (Niklas Cassel)
* pci/controller/dwc:
PCI: dw-rockchip: Hide broken ATS capability for RK3588 running in EP mode
PCI: dwc: ep: Add dw_pcie_ep_hide_ext_capability()
PCI: dwc: ep: Return -ENOMEM for allocation failures
PCI: dwc: Add Rockchip to the RAS DES allowed vendor list
PCI: Add Rockchip Vendor ID
PCI: dwc: Add debugfs property to provide LTSSM status of the PCIe link
PCI: dwc: Add debugfs based Statistical Counter support for DWC
PCI: dwc: Add debugfs based Error Injection support for DWC
PCI: dwc: Add debugfs based Silicon Debug support for DWC
PCI: dwc: Add helper to find the Vendor Specific Extended Capability (VSEC)
perf/dwc_pcie: Move common DWC struct definitions to 'pcie-dwc.h'
|
|
We know the parent_bus_offset, either computed from a DT reg property (the
offset is the CPU physical addr - the 'config'/'addr_space' address on the
parent bus) or from a .cpu_addr_fixup() (which may have used a host bridge
window offset).
Apply that parent_bus_offset instead of calling .cpu_addr_fixup() when
programming the ATU.
This assumes all intermediate addresses are at the same offset from the CPU
physical addresses.
[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20250315201548.858189-13-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Most systems' PCIe outbound map windows have non-zero physical addresses,
but the possibility of encountering zero increased after following commit
("PCI: dwc: Use parent_bus_offset").
'ep->outbound_addr[n]', representing 'parent_bus_address', might be 0 on
some hardware, which trims high address bits through bus fabric before
sending to the PCIe controller.
Replace the iteration logic with 'for_each_set_bit()' to ensure only
allocated map windows are iterated when determining the ATU index from a
given address.
Link: https://lore.kernel.org/r/20250315201548.858189-12-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Endpoint
┌───────────────────────────────────────────────┐
│ pcie-ep@5f010000 │
│ ┌────────────────┐│
│ │ Endpoint ││
│ │ PCIe ││
│ │ Controller ││
│ bus@5f000000 │ ┌────────►
│ ┌──────────┐ │ │ ││dynamically
│ │ │ Outbound Transfer │ ││allocated
│┌─────┐ │ Bus ┼─────►│ ATU ───────┘ ││PCI Addr
││ │ │ Fabric │Bus │ ││
││ CPU ├───►│ │Addr │ ││
││ │CPU │ │0x8000_0000 ││
│└─────┘Addr└──────────┘ │ ││
│ 0x7000_0000 └────────────────┘│
└───────────────────────────────────────────────┘
bus@5f000000 {
compatible = "simple-bus";
ranges = <0x80000000 0x0 0x70000000 0x10000000>;
pcie-ep@5f010000 {
reg = <0x80000000 0x10000000>;
reg-names ="addr_space";
...
};
...
};
In the diagram above, CPU writes data to outbound window address
0x7000_0000, and the bus fabric maps it to 0x8000_0000. The ATU uses
bus address 0x8000_0000 as input address and maps to some PCI address
dynamically allocated by a PCI device driver on the host side.
The pcie-ep@5f010000 'reg[addr_space]' is the parent bus address, which is
the input of PCIe controller, including the ATU.
Set parent_bus_offset, the offset from the CPU address to the PCIe
controller input address using dw_pcie_init_parent_bus_offset(). The
parent_bus_offset is not used yet, so no functional change intended.
[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20250315201548.858189-11-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Consolidate devicetree resource handling in dw_pcie_ep_get_resources().
No functional change intended.
Link: https://lore.kernel.org/r/20250315201548.858189-10-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
|
|
Move devm_pci_epc_create() to the beginning of dw_pcie_ep_init().
devm_pci_epc_create() is generic code that doesn't depend on any DWC
resource, so moving it earlier keeps all the subsequent devicetree-related
code together.
Link: https://lore.kernel.org/r/20250315201548.858189-9-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
|
|
Rename 'cpu_addr' to 'parent_bus_addr' in the DesignWare ATU configuration.
The ATU translates parent bus addresses to PCI addresses, which are often
the same as CPU addresses but can differ in systems where the bus fabric
translates addresses before passing them to the PCIe controller. This
renaming clarifies the purpose and avoids confusion.
Link: https://lore.kernel.org/r/20250315201548.858189-3-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Add dw_pcie_ep_hide_ext_capability() which can be used by an endpoint
controller driver to hide a capability.
This can be useful to hide a capability that is buggy, such that the
host side does not try to enable the buggy capability.
Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Link: https://lore.kernel.org/r/20250310094826.842681-5-cassel@kernel.org
|
|
If the bitmap or memory allocations fail, then dw_pcie_ep_init_registers()
will incorrectly return a success.
Return -ENOMEM instead.
Fixes: 869bc5253406 ("PCI: dwc: ep: Fix DBI access failure for drivers requiring refclk from host")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/36dcb6fc-f292-4dd5-bd45-a8c6f9dc3df7@stanley.mountain
|
|
Remove the superfluous function dw_pcie_ep_find_ext_capability(),
as it is virtually identical to dw_pcie_find_ext_capability().
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20250221202646.395252-3-cassel@kernel.org
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
The DWC databook specifies three different BARn_SIZING_SCHEME_N as:
- Fixed Mask (0)
- Programmable Mask (1)
- Resizable BAR (2)
Each of these sizing schemes have different instructions for how to
initialize the BAR.
The DWC driver currently does not support resizable BARs.
Instead, in order to somewhat support resizable BARs, the DWC EP driver
currently has an ugly hack that force sets a resizable BAR to 1 MB, if
such a BAR is detected.
Additionally, this hack only works if the DWC glue driver also has lied
in their EPC features, and claimed that the resizable BAR is a 1 MB fixed
size BAR.
This is unintuitive (as you somehow need to know that you need to lie in
your EPC features), but other than that it is overly restrictive, since a
resizable BAR is capable of supporting sizes different than 1 MB.
Add proper support for resizable BARs in the DWC EP driver.
Note that the pci_epc_set_bar() API takes a struct pci_epf_bar which tells
the EPC driver how it wants to configure the BAR.
struct pci_epf_bar only has a single size struct member.
This means that an EPC driver will only be able to set a single supported
size. This is perfectly fine, as we do not need the complexity of allowing
a host to change the size of the BAR. If someone ever wants to support
resizing a resizable BAR, the pci_epc_set_bar() API can be extended in the
future.
With these changes, we allow an EPF driver to configure the size of
Resizable BARs, rather than forcing them to a 1 MB size.
This means that an EPC driver does not need to lie in EPC features, and an
EPF driver will be able to set an arbitrary size (not be forced to a 1 MB
size), just like BAR_PROGRAMMABLE.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20250131182949.465530-13-cassel@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
Move dw_pcie_ep_find_ext_capability() so that it is located next to
dw_pcie_ep_find_capability().
Additionally, a follow-up commit requires this to be defined earlier
in order to avoid a forward declaration.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20250131182949.465530-12-cassel@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
Add support to provide Silicon Debug interface to userspace.
This set of debug registers are part of the RAS DES feature present in
DesignWare PCIe controllers.
Co-developed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Tested-by: Hrishikesh Deleep <hrishikesh.d@samsung.com>
Link: https://lore.kernel.org/r/20250221131548.59616-4-shradha.t@samsung.com
[kwilczynski: commit log, tidy up Kconfig and drop "default y", tidy up
code comments, squashed patch that fixes a NULL pointer dereference when
debugfs is already unavailable during clean-up from
https://lore.kernel.org/linux-pci/20250225171239.19574-2-manivannan.sadhasivam@linaro.org,
refactor dwc_pcie_debugfs_init() to not return errors, squashed patch that
changes how lack of the RAS DES capability is handled from
https://lore.kernel.org/linux-pci/20250304151814.6xu7cbpwpqrvcad5@thinkpad]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
dw_pcie_prog_ep_inbound_atu()
dw_pcie_prog_ep_inbound_atu() is used to program an inbound iATU in
"BAR Match Mode".
A memory address returned by e.g. kmalloc() is guaranteed to have natural
alignment (aligned to the size of the allocation). It is however not
guaranteed that pci_epc_set_bar() (and thus dw_pcie_prog_ep_inbound_atu())
is supplied an address that has natural alignment. (An EPF driver can send
in an arbitrary physical address to pci_epc_set_bar().)
The DWC Databook description for the LWR_TARGET_RW and LWR_TARGET_HW fields
in the IATU_LWR_TARGET_ADDR_OFF_INBOUND_i registers state that:
"Field size depends on log2(BAR_MASK+1) in BAR match mode."
I.e. only the upper bits are writable, and the number of writable bits is
dependent on the configured BAR_MASK.
Add a check to ensure that the physical address programmed in the iATU is
aligned to the size of the BAR (BAR_MASK+1), as without this, we can get
hard to debug errors, as we could write to bits that are read-only (without
getting a write error), which could cause the iATU to end up redirecting to
a physical address that is different from the address that we intended.
Link: https://lore.kernel.org/r/20241213143301.4158431-11-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
|
In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update
inbound map address") set_bar() was modified to support dynamically
changing the backing physical address of a BAR that was already configured.
This means that set_bar() can be called twice, without ever calling
clear_bar() (as calling clear_bar() would clear the BAR's PCI address
assigned by the host).
This can only be done if the new BAR size/flags does not differ from the
existing BAR configuration. Add these missing checks.
If we allow set_bar() to set e.g. a new BAR size that differs from the
existing BAR size, the new address translation range will be smaller than
the BAR size already determined by the host, which would mean that a read
past the new BAR size would pass the iATU untranslated, which could allow
the host to read memory not belonging to the new struct pci_epf_bar.
While at it, add comments which clarifies the support for dynamically
changing the physical address of a BAR. (Which was also missing.)
Fixes: 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address")
Link: https://lore.kernel.org/r/20241213143301.4158431-10-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: stable@vger.kernel.org
|
|
The "DesignWare Cores PCI Express Controller Register Descriptions,
Version 4.60a", section "1.21.70 IATU_LWR_TARGET_ADDR_OFF_INBOUND_i",
fields LWR_TARGET_RW and LWR_TARGET_HW both state that:
"Field size depends on log2(BAR_MASK+1) in BAR match mode."
I.e. only the upper bits are writable, and the number of writable bits is
dependent on the configured BAR_MASK.
If we do not write the BAR_MASK before writing the iATU registers, we are
relying the reset value of the BAR_MASK being larger than the requested
BAR size (which is supplied in the struct pci_epf_bar which is passed to
pci_epc_set_bar()). The reset value of the BAR_MASK is SoC dependent.
Thus, if the struct pci_epf_bar requests a BAR size that is larger than the
reset value of the BAR_MASK, the iATU will try to write to read-only bits,
which will cause the iATU to end up redirecting to a physical address that
is different from the address that was intended.
Thus, we should always write the iATU registers after writing the BAR_MASK.
Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support")
Link: https://lore.kernel.org/r/20241213143301.4158431-9-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: stable@vger.kernel.org
|
|
- Clear outbound address on unmap so dw_pcie_find_index() won't match an
ATU index that was already unmapped (Damien Le Moal)
- Use of_property_present() instead of of_property_read_bool() when testing
for presence of non-boolean DT properties (Rob Herring)
- Advertise 1MB size if endpoint supports Resizable BARs, which was
inadvertently lost in v6.11 (Niklas Cassel)
* pci/controller/dwc:
PCI: dwc: ep: Fix advertised resizable BAR size regression
PCI: dwc: Use of_property_present() for non-boolean properties
PCI: dwc: endpoint: Clear outbound address on unmap
|
|
The advertised resizable BAR size was fixed in commit 72e34b8593e0 ("PCI:
dwc: endpoint: Fix advertised resizable BAR size").
Commit 867ab111b242 ("PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown()
API to handle Link Down event") was included shortly after this, and
moved the code to another function. When the code was moved, this fix
was mistakenly lost.
According to the spec, it is illegal to not have a bit set in
PCI_REBAR_CAP, and 1 MB is the smallest size allowed.
So, set bit 4 in PCI_REBAR_CAP, so that we actually advertise support
for a 1 MB BAR size.
Fixes: 867ab111b242 ("PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down event")
Link: https://lore.kernel.org/r/20241116005950.2480427-2-cassel@kernel.org
Link: https://lore.kernel.org/r/20240606-pci-deinit-v1-3-4395534520dc@linaro.org
Link: https://lore.kernel.org/r/20240307111520.3303774-1-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Cc: stable@vger.kernel.org
|
|
Use the dw_pcie_ep_align_addr() function to calculate the alignment in
dw_pcie_ep_raise_{msi,msix}_irq() instead of open coding the same.
Link: https://lore.kernel.org/r/20241017132052.4014605-6-cassel@kernel.org
Link: https://lore.kernel.org/r/20241104205144.409236-2-cassel@kernel.org
Tested-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
[kwilczynski: squashed patch that fixes memory map sizes]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
|
The function dw_pcie_prog_outbound_atu() used to program outbound ATU
entries for mapping RC PCI addresses to local CPU addresses does not
allow PCI addresses that are not aligned to the value of region_align
of struct dw_pcie. This value is determined from the iATU hardware
registers during probing of the iATU (done by dw_pcie_iatu_detect()).
This value is thus valid for all DWC PCIe controllers, and valid
regardless of the hardware configuration used when synthesizing the
DWC PCIe controller.
Implement the ->align_addr() endpoint controller operation to allow
this mapping alignment to be transparently handled by endpoint function
drivers through the function pci_epc_mem_map().
Link: https://lore.kernel.org/linux-pci/20241012113246.95634-7-dlemoal@kernel.org
Link: https://lore.kernel.org/linux-pci/20241015090712.112674-1-dlemoal@kernel.org
Link: https://lore.kernel.org/linux-pci/20241017132052.4014605-5-cassel@kernel.org
Co-developed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
[mani: squashed the patch that changed phy_addr_t to u64]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[kwilczynski: squashed patch that updated the pci_size variable]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
|
Clear the address mapped (outbound_addr array) in dw_pcie_ep_unmap_addr(),
to ensure that dw_pcie_find_index() does not match an ATU index that was
already unmapped.
This is in addition to clearing the ATU index bit in ob_window_map.
Link: https://lore.kernel.org/linux-pci/20241004141000.5080-1-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
|
From the DWC EP databook 5.96a, section "3.5.7.1.4 General Rules for BAR
Setup (Fixed Mask or Programmable Mask Schemes Only)":
"Any pair (for example BARs 0 and 1) can be configured as one 64-bit BAR,
two 32-bit BARs, or one 32-bit BAR."
"BAR pairs cannot overlap to form a 64-bit BAR. For example, you cannot
combine BARs 1 and 2 to form a 64-bit BAR."
While this limitation does exist in some other PCI endpoint controllers,
e.g. cdns_pcie_ep_set_bar(), the limitation does not appear to be defined
in the PCIe specification itself, thus add an explicit check for this in
dw_pcie_ep_set_bar() (rather than pci_epc_set_bar()).
Link: https://lore.kernel.org/linux-pci/20240528134839.8817-2-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
|
Currently dw_pcie_ep_init_notify() wrapper just calls pci_epc_init_notify()
directly, so this wrapper provides no benefit to the glue drivers.
Remove it and call pci_epc_init_notify() directly from glue drivers.
Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
Link: https://lore.kernel.org/linux-pci/20240606-pci-deinit-v1-1-4395534520dc@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
|
|
Per PCIe r6.0, sec 5.2, a Link Down event can happen under any of the
following circumstances:
1. Fundamental/Hot reset
2. Link disable transmission by upstream component
3. Moving from L2/L3 to L0
In those cases, Link Down causes some non-sticky DWC registers to lose the
state (like REBAR, etc.), so drivers need to reinitialize them to function
properly once the link comes back again.
This is not a problem for drivers supporting PERST# IRQ, since they can
reinitialize the registers in the PERST# IRQ callback. But for the drivers
not supporting PERST#, there is no way they can reinitialize the registers
other than relying on Link Down IRQ received when the link goes down. So
add a DWC generic API dw_pcie_ep_linkdown() that reinitializes the
non-sticky registers and also notifies the EPF drivers about link going
down.
This API can also be used by the drivers supporting PERST# to handle the
scenario (2) mentioned above.
NOTE: For the sake of code organization, move the dw_pcie_ep_linkup()
definition just above dw_pcie_ep_linkdown().
Link: https://lore.kernel.org/linux-pci/20240430-pci-epf-rework-v4-8-22832d0d456f@linaro.org
Tested-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: update spec citation]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
|
|
This is a preparation before adding the Msg-type outbound iATU
mapping. The respective update will require two more arguments added
to __dw_pcie_prog_outbound_atu(). That will make the already
complicated function prototype even more hard to comprehend accepting
_eight_ arguments.
To prevent that and keep the code more-or-less readable, move all the
outbound iATU-related arguments to a new config structure: struct
dw_pcie_ob_atu_cfg, and pass a pointer to dw_pcie_prog_outbound_atu(). The
structure should be locally defined and populated with the outbound iATU
settings implied by the caller context.
As a result of this change there is no longer need in having the two
distinctive methods for the Host and Endpoint outbound iATU setups since
the code can directly call the dw_pcie_prog_outbound_atu() method with the
config structure populated, so drop dw_pcie_prog_ep_outbound_atu().
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20240418-pme_msg-v8-2-a54265c39742@nxp.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
|
|
When PERST# assert and deassert happens on the PERST# supported platforms,
both iATU0 and iATU6 will map inbound window to BAR0. DMA will access the
area that was previously allocated (iATU0) for BAR0, instead of the new
area (iATU6) for BAR0.
Right now, this isn't an issue because both iATU0 and iATU6 should
translate inbound accesses to BAR0 to the same allocated memory area.
However, having two separate inbound mappings for the same BAR is a
disaster waiting to happen.
The mappings between PCI BAR and iATU inbound window are maintained in the
dw_pcie_ep::bar_to_atu[] array. While allocating a new inbound iATU map for
a BAR, dw_pcie_ep_inbound_atu() API checks for the availability of the
existing mapping in the array and if it is not found (i.e., value in the
array indexed by the BAR is found to be 0), it allocates a new map value
using find_first_zero_bit().
The issue is the existing logic failed to consider the fact that the map
value '0' is a valid value for BAR0, so find_first_zero_bit() will return
'0' as the map value for BAR0 (note that it returns the first zero bit
position).
Due to this, when PERST# assert + deassert happens on the PERST# supported
platforms, the inbound window allocation restarts from BAR0 and the
existing logic to find the BAR mapping will return '6' for BAR0 instead of
'0' due to the fact that it considers '0' as an invalid map value.
Fix this issue by always incrementing the map value before assigning to
bar_to_atu[] array and then decrementing it while fetching. This will make
sure that the map value '0' always represents the invalid mapping."
Fixes: 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address")
Closes: https://lore.kernel.org/linux-pci/ZXsRp+Lzg3x%2Fnhk3@x1-carbon/
Link: https://lore.kernel.org/linux-pci/20240412160841.925927-1-Frank.Li@nxp.com
Reported-by: Niklas Cassel <Niklas.Cassel@wdc.com>
Tested-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
|
|
As like the 'epc_init' event, that is used to signal the EPF drivers about
the EPC initialization, let's introduce 'epc_deinit' event that is used to
signal EPC deinitialization.
The EPC deinitialization applies only when any sort of fundamental reset
is supported by the endpoint controller as per the PCIe spec.
Reference: PCIe r6.0, sec 4.2.5.9.1 and 6.6.1.
Currently, some EPC drivers like pcie-qcom-ep and pcie-tegra194 support
PERST# as the fundamental reset. So the 'deinit' event will be notified to
the EPF drivers when PERST# assert happens in the above mentioned EPC
drivers.
The EPF drivers, on receiving the event through the epc_deinit() callback
should reset the EPF state machine and also cleanup any configuration that
got affected by the fundamental reset like BAR, DMA etc...
This change also warrants skipping the cleanups in unbind() if already done
in epc_deinit().
Link: https://lore.kernel.org/r/20240606-pci-deinit-v1-2-4395534520dc@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
|
|
"core_init_notifier" flag is set by the glue drivers requiring refclk from
the host to complete the DWC core initialization. Also, those drivers will
send a notification to the EPF drivers once the initialization is fully
completed using the pci_epc_init_notify() API. Only then, the EPF drivers
will start functioning.
For the rest of the drivers generating refclk locally, EPF drivers will
start functioning post binding with them. EPF drivers rely on the
'core_init_notifier' flag to differentiate between the drivers.
Unfortunately, this creates two different flows for the EPF drivers.
So to avoid that, let's get rid of the "core_init_notifier" flag and follow
a single initialization flow for the EPF drivers. This is done by calling
the dw_pcie_ep_init_notify() from all glue drivers after the completion of
dw_pcie_ep_init_registers() API. This will allow all the glue drivers to
send the notification to the EPF drivers once the initialization is fully
completed.
Only difference here is that, the drivers requiring refclk from host will
send the notification once refclk is received, while others will send it
during probe time itself.
But this also requires the EPC core driver to deliver the notification
after EPF driver bind. Because, the glue driver can send the notification
before the EPF drivers bind() and in those cases the EPF drivers will miss
the event. To accommodate this, EPC core is now caching the state of the
EPC initialization in 'init_complete' flag and pci-ep-cfs driver sends the
notification to EPF drivers based on that after each EPF driver bind.
Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-8-082625472414@linaro.org
Tested-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
|
|
drivers
Currently, dw_pcie_ep_init_registers() API is directly called by the glue
drivers requiring active refclk from host. But for the other drivers, it is
getting called implicitly by dw_pcie_ep_init(). This is due to the fact
that this API initializes DWC EP specific registers and that requires an
active refclk (either from host or generated locally by endpoint itsef).
But, this causes a discrepancy among the glue drivers. So to avoid this
confusion, let's call this API directly from all glue drivers irrespective
of refclk dependency. Only difference here is that the drivers requiring
refclk from host will call this API only after the refclk is received and
other drivers without refclk dependency will call this API right after
dw_pcie_ep_init().
With this change, the check for 'core_init_notifier' flag can now be
dropped from dw_pcie_ep_init() API. This will also allow us to remove the
'core_init_notifier' flag completely in the later commits.
Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-7-082625472414@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
|
The goal of the dw_pcie_ep_init_complete() API is to initialize the DWC
specific registers post registering the controller with the EP framework.
But the naming doesn't reflect its functionality and causes confusion. So,
let's rename it to dw_pcie_ep_init_registers() to make it clear that it
initializes the DWC specific registers.
Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-6-082625472414@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
|
|
For DWC glue drivers supporting PERST# (currently Qcom and Tegra194), some
of the DWC resources like eDMA should be cleaned up during the PERST#
assert time.
So let's introduce a dw_pcie_ep_cleanup() API that could be called by these
drivers to cleanup the DWC specific resources. Currently, it just removes
eDMA.
Closes: https://lore.kernel.org/linux-pci/ZWYmX8Y%2F7Q9WMxES@x1-carbon
Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-5-082625472414@linaro.org
Reported-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
|
|
dw_pcie_ep_exit() API is undoing what the dw_pcie_ep_init() API has done
already (at least partly). But the API name dw_pcie_ep_exit() is not quite
reflecting that. So let's rename it to dw_pcie_ep_deinit() to make the
purpose of this API clear. This also aligns with the DWC host driver.
Link: https://patchwork.kernel.org/project/linux-pci/patch/20240327-pci-dbi-rework-v12-4-082625472414@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
|
deinit() callback was solely introduced for the pcie-rcar-gen4 driver where
it is used to do platform specific resource deallocation. And this callback
is called right at the end of the dw_pcie_ep_exit() API. So it doesn't
matter whether it is called within or outside of dw_pcie_ep_exit() API.
So let's remove this callback and directly call rcar_gen4_pcie_ep_deinit()
in pcie-rcar-gen4 driver to do resource deallocation after the completion
of dw_pcie_ep_exit() API in rcar_gen4_remove_dw_pcie_ep().
This simplifies the DWC layer.
Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-3-082625472414@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
|
All of the APIs are missing the Kernel-doc comments. Hence, add them.
Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-2-082625472414@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
|
|
The DWC glue drivers requiring an active reference clock from the PCIe host
for initializing their PCIe EP core, set a flag called 'core_init_notifier'
to let DWC driver know that these drivers need a special attention during
initialization. In these drivers, access to the hw registers (like DBI)
before receiving the active refclk from host will result in access failure
and also could cause a whole system hang.
But the current DWC EP driver doesn't honor the requirements of the drivers
setting 'core_init_notifier' flag and tries to access the DBI registers
during dw_pcie_ep_init(). This causes the system hang for glue drivers such
as Tegra194 and Qcom EP as they depend on refclk from host and have set the
above mentioned flag.
To workaround this issue, users of the affected platforms have to maintain
the dependency with the PCIe host by booting the PCIe EP after host boot.
But this won't provide a good user experience, since PCIe EP is _one_ of
the features of those platforms and it doesn't make sense to delay the
whole platform booting due to PCIe requiring active refclk.
So to fix this issue, let's move all the DBI access from
dw_pcie_ep_init() in the DWC EP driver to the dw_pcie_ep_init_complete()
API. This API will only be called by the drivers setting
'core_init_notifier' flag once refclk is received from host. For the rest
of the drivers that gets the refclk locally, this API will be called
within dw_pcie_ep_init().
Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-1-082625472414@linaro.org
Fixes: e966f7390da9 ("PCI: dwc: Refactor core initialization code for EP mode")
Co-developed-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
Pull PCI updates from Bjorn Helgaas:
"Enumeration:
- Consolidate interrupt related code in irq.c (Ilpo Järvinen)
- Reduce kernel size by replacing sysfs resource macros with
functions (Ilpo Järvinen)
- Reduce kernel size by compiling sysfs support only when
CONFIG_SYSFS=y (Lukas Wunner)
- Avoid using Extended Tags on 3ware-9650SE Root Port to work around
an apparent hardware defect (Jörg Wedekind)
Resource management:
- Fix an MMIO mapping leak in pci_iounmap() (Philipp Stanner)
- Move pci_iomap.c and other PCI-specific devres code to drivers/pci
(Philipp Stanner)
- Consolidate PCI devres code in devres.c (Philipp Stanner)
Power management:
- Avoid D3cold on Asus B1400 PCI-NVMe bridge, where firmware doesn't
know how to return correctly to D0, and remove previous quirk that
wasn't as specific (Daniel Drake)
- Allow runtime PM when the driver enables it but doesn't need any
runtime PM callbacks (Raag Jadav)
- Drain runtime-idle callbacks before driver removal to avoid races
between .remove() and .runtime_idle(), which caused intermittent
page faults when the rtsx .runtime_idle() accessed registers that
its .remove() had already unmapped (Rafael J. Wysocki)
Virtualization:
- Avoid Secondary Bus Reset on LSI FW643 so it can be assigned to VMs
with VFIO, e.g., for professional audio software on many Apple
machines, at the cost of leaking state between VMs (Edmund Raile)
Error handling:
- Print all logged TLP Prefixes, not just the first, after AER or DPC
errors (Ilpo Järvinen)
- Quirk the DPC PIO log size for Intel Raptor Lake Root Ports, which
still don't advertise a legal size (Paul Menzel)
- Ignore expected DPC Surprise Down errors on hot removal (Smita
Koralahalli)
- Block runtime suspend while handling AER errors to avoid races that
prevent the device form being resumed from D3hot (Stanislaw
Gruszka)
Peer-to-peer DMA:
- Use atomic XA allocation in RCU read section (Christophe JAILLET)
ASPM:
- Collect bits of ASPM-related code that we need even without
CONFIG_PCIEASPM into aspm.c (David E. Box)
- Save/restore L1 PM Substates config for suspend/resume (David E.
Box)
- Update save_save when ASPM config is changed, so a .slot_reset()
during error recovery restores the changed config, not the
.probe()-time config (Vidya Sagar)
Endpoint framework:
- Refactor and improve pci_epf_alloc_space() API (Niklas Cassel)
- Clean up endpoint BAR descriptions (Niklas Cassel)
- Fix ntb_register_device() name leak in error path (Yang Yingliang)
- Return actual error code for pci_vntb_probe() failure (Yang
Yingliang)
Broadcom STB PCIe controller driver:
- Fix MDIO write polling, which previously never waited for
completion (Jonathan Bell)
Cadence PCIe endpoint driver:
- Clear the ARI "Next Function Number" of last function (Jasko-EXT
Wojciech)
Freescale i.MX6 PCIe controller driver:
- Simplify by replacing switch statements with function pointers for
different hardware variants (Frank Li)
- Simplify by using clk_bulk*() API (Frank Li)
- Remove redundant DT clock and reg/reg-name details (Frank Li)
- Add i.MX95 DT and driver support for both Root Complex and Endpoint
mode (Frank Li)
Microsoft Hyper-V host bridge driver:
- Reduce memory usage by limiting ring buffer size to 16KB instead of
4 pages (Michael Kelley)
Qualcomm PCIe controller driver:
- Add X1E80100 DT and driver support (Abel Vesa)
- Add DT 'required-opps' for SoCs that require a minimum performance
level (Johan Hovold)
- Make DT 'msi-map-mask' optional, depending on how MSI interrupts
are mapped (Johan Hovold)
- Disable ASPM L0s for sc8280xp, sa8540p and sa8295p because the PHY
configuration isn't tuned correctly for L0s (Johan Hovold)
- Split dt-binding qcom,pcie.yaml into qcom,pcie-common.yaml and
separate files for SA8775p, SC7280, SC8180X, SC8280XP, SM8150,
SM8250, SM8350, SM8450, SM8550 for easier reviewing (Krzysztof
Kozlowski)
- Enable BDF to SID translation by disabling bypass mode (Manivannan
Sadhasivam)
- Add endpoint MHI support for Snapdragon SA8775P SoC (Mrinmay
Sarkar)
Synopsys DesignWare PCIe controller driver:
- Allocate 64-bit MSI address if no 32-bit address is available (Ajay
Agarwal)
- Fix endpoint Resizable BAR to actually advertise the required 1MB
size (Niklas Cassel)
MicroSemi Switchtec management driver:
- Release resources if the .probe() fails (Christophe JAILLET)
Miscellaneous:
- Make pcie_port_bus_type const (Ricardo B. Marliere)"
* tag 'pci-v6.9-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: (77 commits)
PCI/ASPM: Update save_state when configuration changes
PCI/ASPM: Disable L1 before configuring L1 Substates
PCI/ASPM: Call pci_save_ltr_state() from pci_save_pcie_state()
PCI/ASPM: Save L1 PM Substates Capability for suspend/resume
PCI: hv: Fix ring buffer size calculation
PCI: dwc: endpoint: Fix advertised resizable BAR size
PCI: cadence: Clear the ARI Capability Next Function Number of the last function
PCI: dwc: Strengthen the MSI address allocation logic
PCI: brcmstb: Fix broken brcm_pcie_mdio_write() polling
PCI: qcom: Add X1E80100 PCIe support
dt-bindings: PCI: qcom: Document the X1E80100 PCIe Controller
PCI: qcom: Enable BDF to SID translation properly
PCI/AER: Generalize TLP Header Log reading
PCI/AER: Use explicit register size for PCI_ERR_CAP
PCI: qcom: Disable ASPM L0s for sc8280xp, sa8540p and sa8295p
dt-bindings: PCI: qcom: Do not require 'msi-map-mask'
dt-bindings: PCI: qcom: Allow 'required-opps'
PCI/AER: Block runtime suspend when handling errors
PCI/ASPM: Move pci_save_ltr_state() to aspm.c
PCI/ASPM: Always build aspm.c
...
|
|
The commit message in commit fc9a77040b04 ("PCI: designware-ep: Configure
Resizable BAR cap to advertise the smallest size") claims that it modifies
the Resizable BAR capability to only advertise support for 1 MB size BARs.
However, the commit writes all zeroes to PCI_REBAR_CAP (the register which
contains the possible BAR sizes that a BAR be resized to).
According to the spec, it is illegal to not have a bit set in
PCI_REBAR_CAP, and 1 MB is the smallest size allowed.
Set bit 4 in PCI_REBAR_CAP, so that we actually advertise support for a
1 MB BAR size.
Before:
Capabilities: [2e8 v1] Physical Resizable BAR
BAR 0: current size: 1MB
BAR 1: current size: 1MB
BAR 2: current size: 1MB
BAR 3: current size: 1MB
BAR 4: current size: 1MB
BAR 5: current size: 1MB
After:
Capabilities: [2e8 v1] Physical Resizable BAR
BAR 0: current size: 1MB, supported: 1MB
BAR 1: current size: 1MB, supported: 1MB
BAR 2: current size: 1MB, supported: 1MB
BAR 3: current size: 1MB, supported: 1MB
BAR 4: current size: 1MB, supported: 1MB
BAR 5: current size: 1MB, supported: 1MB
Fixes: fc9a77040b04 ("PCI: designware-ep: Configure Resizable BAR cap to advertise the smallest size")
Link: https://lore.kernel.org/linux-pci/20240307111520.3303774-1-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: <stable@vger.kernel.org> # 5.2
|
|
I recently changed the alignment code in dw_pcie_ep_raise_msix_irq(). The
code in dw_pcie_ep_raise_msi_irq() is similar, so update it to match, just
for consistency. (No effect on runtime, just a cleanup).
Link: https://lore.kernel.org/r/184097e0-c728-42c7-9e8a-556bd33fb612@moroto.mountain
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
|
The "msg_addr" variable is u64. However, the "aligned_offset" is an
unsigned int. This means that when the code does:
msg_addr &= ~aligned_offset;
it will unintentionally zero out the high 32 bits. Use ALIGN_DOWN() to do
the alignment instead.
Fixes: 2217fffcd63f ("PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support")
Link: https://lore.kernel.org/r/af59c7ad-ab93-40f7-ad4a-7ac0b14d37f5@moroto.mountain
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: <stable@vger.kernel.org>
|
|
- Rename PCI_IRQ_LEGACY to PCI_IRQ_INTX to be more explicit and match spec
terminology (Bjorn Helgaas)
- Use existing PCI_IRQ_INTX, PCI_IRQ_MSI, PCI_IRQ_MSIX in artpec6, cadence,
designware, designware-plat, dra7xx, imx6, keembay, keystone, layerscape,
mhi, ntb, qcom, rcar, rcar-gen4, rockchip, tegra194, uniphier, vntb; drop
the redundant pci_epc_irq_type enum with the same values (Damien Le Moal)
- Use "intx" instead of "leg" or "legacy" when describing INTx interrupts
in endpoint core, endpoint tests, cadence, dra7xx, designware,
dw-rockchip, dwc core, imx6, keystone, layerscape, qcom, rcar-gen4,
rockchip, tegra194, uniphier, xilinx-nwl (Damien Le Moal)
* pci/irq-clean-up:
PCI: xilinx-nwl: Use INTX instead of legacy
PCI: rockchip-host: Rename rockchip_pcie_legacy_int_handler()
PCI: rockchip-ep: Use INTX instead of legacy
PCI: uniphier: Use INTX instead of legacy
PCI: tegra194: Use INTX instead of legacy
PCI: dw-rockchip: Rename rockchip_pcie_legacy_int_handler()
PCI: keystone: Use INTX instead of legacy
PCI: dwc: Rename dw_pcie_ep_raise_legacy_irq()
PCI: cadence: Use INTX instead of legacy
PCI: dra7xx: Rename dra7xx_pcie_raise_legacy_irq()
misc: pci_endpoint_test: Use INTX instead of LEGACY
PCI: endpoint: Rename LEGACY to INTX in test function driver
PCI: endpoint: Use INTX instead of legacy
PCI: endpoint: Drop PCI_EPC_IRQ_XXX definitions
PCI: Rename PCI_IRQ_LEGACY to PCI_IRQ_INTX
|
|
The current code calculated some dbi[2] registers' offset by calling
dw_pcie_ep_get_dbi[2]_offset() in each function. To improve the code
readability, add dw_pcie_ep_{read,write}_dbi[2} and some data-width
related helpers.
Link: https://lore.kernel.org/linux-pci/20231220053829.1921187-5-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
|
Since the struct member .func_conf_select makes the intentions behind it
difficult to ascertain from its name alone, rename it to .get_dbi_offset
to make the intended usage more obvious.
[kwilczynski: commmit log]
Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/linux-pci/20231220053829.1921187-4-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Since the name of the dw_pcie_ep_ops struct makes it obvious that it's
for the PCIe Endpoint, rename the struct member .ep_init to .init.
[kwilczynski: commit log]
Suggested-by: Serge Semin <fancer.lancer@gmail.com>
Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/linux-pci/20231220053829.1921187-3-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Srikanth Thokala <srikanth.thokala@intel.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
|
|
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>
|
|
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>
|
|
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 FIELD_GET()/FIELD_PREP() when possible throughout drivers/pci/ (Ilpo
Järvinen, Bjorn Helgaas)
- Rework DPC control programming for clarity (Ilpo Järvinen)
* pci/field-get:
PCI/portdrv: Use FIELD_GET()
PCI/VC: Use FIELD_GET()
PCI/PTM: Use FIELD_GET()
PCI/PME: Use FIELD_GET()
PCI/ATS: Use FIELD_GET()
PCI/ATS: Show PASID Capability register width in bitmasks
PCI: Use FIELD_GET() in Sapphire RX 5600 XT Pulse quirk
PCI: Use FIELD_GET()
PCI/MSI: Use FIELD_GET/PREP()
PCI/DPC: Use defines with DPC reason fields
PCI/DPC: Use defined fields with DPC_CTL register
PCI/DPC: Use FIELD_GET()
PCI: hotplug: Use FIELD_GET/PREP()
PCI: dwc: Use FIELD_GET/PREP()
PCI: cadence: Use FIELD_GET()
PCI: Use FIELD_GET() to extract Link Width
PCI: mvebu: Use FIELD_PREP() with Link Width
PCI: tegra194: Use FIELD_GET()/FIELD_PREP() with Link Width fields
# Conflicts:
# drivers/pci/controller/dwc/pcie-tegra194.c
|
|
Convert open-coded variants of PCI field access into FIELD_GET/PREP()
to make the code easier to understand.
Add two missing defines into pci_regs.h. Logically, the Max No-Snoop
Latency Register is a separate word sized register in the PCIe spec,
but the pre-existing LTR defines in pci_regs.h with dword long values
seem to consider the registers together (the same goes for the only
user). Thus, follow the custom and make the new values also take both
word long LTR registers as a joint dword register.
Link: https://lore.kernel.org/r/20231024110336.26264-1-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Renesas R-Car Gen4 PCIe controllers require vendor-specific
initialization before .init().
To use dw->dbi and dw->num-lanes in the initialization code,
introduce .pre_init() into struct dw_pcie_ep_ops. While at it,
also introduce .deinit() to disable the controller by using
vendor-specific de-initialization.
Note that the ep_init in the struct dw_pcie_ep_ops should be
renamed to init later.
Link: https://lore.kernel.org/linux-pci/20231018085631.1121289-9-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
|
