#
92446499 |
| 12-Apr-2024 |
Frank Li <Frank.Li@nxp.com> |
PCI: dwc: Fix index 0 incorrectly being interpreted as a free ATU slot
[ Upstream commit c2a57ee0f2f1ad8c970ff58b78a43e85abbdeb7f ]
When PERST# assert and deassert happens on the PERST# supported p
PCI: dwc: Fix index 0 incorrectly being interpreted as a free ATU slot
[ Upstream commit c2a57ee0f2f1ad8c970ff58b78a43e85abbdeb7f ]
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> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cebb4bae |
| 07-Mar-2024 |
Niklas Cassel <cassel@kernel.org> |
PCI: dwc: endpoint: Fix advertised resizable BAR size
[ Upstream commit 72e34b8593e08a0ee759b7a038e0b178418ea6f8 ]
The commit message in commit fc9a77040b04 ("PCI: designware-ep: Configure Resizabl
PCI: dwc: endpoint: Fix advertised resizable BAR size
[ Upstream commit 72e34b8593e08a0ee759b7a038e0b178418ea6f8 ]
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 Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
6ea2f3b9 |
| 26-Jan-2024 |
Dan Carpenter <dan.carpenter@linaro.org> |
PCI: dwc: Fix a 64bit bug in dw_pcie_ep_raise_msix_irq()
commit b5d1b4b46f856da1473c7ba9a5cdfcb55c9b2478 upstream.
The "msg_addr" variable is u64. However, the "aligned_offset" is an unsigned int.
PCI: dwc: Fix a 64bit bug in dw_pcie_ep_raise_msix_irq()
commit b5d1b4b46f856da1473c7ba9a5cdfcb55c9b2478 upstream.
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> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
43501b6c |
| 28-Nov-2023 |
Niklas Cassel <niklas.cassel@wdc.com> |
PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support
commit 2217fffcd63f86776c985d42e76daa43a56abdf1 upstream.
Commit 6f5e193bfb55 ("PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to ge
PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support
commit 2217fffcd63f86776c985d42e76daa43a56abdf1 upstream.
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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
939fbcd5 |
| 13-Jan-2023 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Add Root Port and Endpoint controller eDMA engine support
Since the DW eDMA core now supports eDMA controllers embedded in locally accessible DW PCIe Root Ports and Endpoints, register the
PCI: dwc: Add Root Port and Endpoint controller eDMA engine support
Since the DW eDMA core now supports eDMA controllers embedded in locally accessible DW PCIe Root Ports and Endpoints, register these controllers when possible.
To do that the DW PCIe core driver needs to perform some preparations first. First of all, it needs to find the eDMA controller CSRs base address, whether they are accessible over the Port Logic or iATU unrolled space. Afterwards it can try to auto-detect the eDMA controller availability and number of read/write channels. If none are found the procedure silently returns without error.
Secondly, the platform is supposed to provide either combined or per-channel IRQ signals. If no valid IRQs set is found, the procedure returns without error to be backward compatible with platforms where DW PCIe controllers have eDMA but lack the IRQ description.
Finally, before actually probing the eDMA device we need to allocate LLP items buffers. After that the DW eDMA can be registered. If registration is successful, a message regarding the number of detected Read/Write eDMA channels will be printed to the system as is done for the iATU settings.
Note: the DW PCI controller driver (either host or endpoint mode) is currently always built-in, so if the DW eDMA core is built as a module (CONFIG_DW_EDMA=m), eDMA controllers will not be registered even if the dw-edma module is later loaded.
Link: https://lore.kernel.org/r/20230113171409.30470-28-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: Vinod Koul <vkoul@kernel.org>
show more ...
|
#
ef8c5887 |
| 13-Nov-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Introduce generic resources getter
Currently the DW PCIe Root Port and Endpoint CSR spaces are retrieved in the separate parts of the DW PCIe core driver. It doesn't really make sense sinc
PCI: dwc: Introduce generic resources getter
Currently the DW PCIe Root Port and Endpoint CSR spaces are retrieved in the separate parts of the DW PCIe core driver. It doesn't really make sense since the both controller types have identical set of the core CSR regions: DBI, DBI CS2 and iATU/eDMA. Thus we can simplify the DW PCIe Host and EP initialization methods by moving the platform-specific registers space getting and mapping into a common method. It gets to be even more justified seeing the CSRs base address pointers are preserved in the common DW PCIe descriptor. Note all the OF-based common DW PCIe settings initialization will be moved to the new method too in order to have a single function for all the generic platform properties handling in single place.
A nice side-effect of this change is that the pcie-designware-host.c and pcie-designware-ep.c drivers are cleaned up from all the direct dw_pcie storage modification, which makes the DW PCIe core, Root Port and Endpoint modules more coherent.
Link: https://lore.kernel.org/r/20221113191301.5526-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org>
show more ...
|
#
8522e17d |
| 13-Nov-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Introduce dma-ranges property support for RC-host
In accordance with the generic PCIe Root Port DT-bindings the "dma-ranges" property has the same format as the "ranges" property. The only
PCI: dwc: Introduce dma-ranges property support for RC-host
In accordance with the generic PCIe Root Port DT-bindings the "dma-ranges" property has the same format as the "ranges" property. The only difference is in their semantics. The "dma-ranges" property describes the PCIe-to-CPU memory mapping in opposite to the CPU-to-PCIe mapping of the "ranges" property. Even though the DW PCIe controllers are normally equipped with the internal Address Translation Unit which inbound and outbound tables can be used to implement both properties semantics, it was surprising for me to discover that the host-related part of the DW PCIe driver currently supports the "ranges" property only while the "dma-ranges" windows are just ignored. Having the "dma-ranges" supported in the driver would be very handy for the platforms, that don't tolerate the 1:1 CPU-PCIe memory mapping and require a customized PCIe memory layout. So let's fix that by introducing the "dma-ranges" property support.
First of all we suggest to rename the dw_pcie_prog_inbound_atu() method to dw_pcie_prog_ep_inbound_atu() and create a new version of the dw_pcie_prog_inbound_atu() function. Thus we'll have two methods for the RC and EP controllers respectively in the same way as it has been developed for the outbound ATU setup methods.
Secondly aside with the memory window index and type the new dw_pcie_prog_inbound_atu() function will accept CPU address, PCIe address and size as its arguments. These parameters define the PCIe and CPU memory ranges which will be used to setup the respective inbound ATU mapping. The passed parameters need to be verified against the ATU ranges constraints in the same way as it is done for the outbound ranges.
Finally the DMA-ranges detected for the PCIe controller need to be converted to the inbound ATU entries during the host controller initialization procedure. It will be done in the framework of the dw_pcie_iatu_setup() method. Note before setting the inbound ranges up we need to disable all the inbound ATU entries in order to prevent unexpected PCIe TLPs translations defined by some third party software like bootloaders.
Link: https://lore.kernel.org/r/20221113191301.5526-16-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
show more ...
|
#
442ae919 |
| 19-Sep-2022 |
Vidya Sagar <vidyas@nvidia.com> |
PCI: designware-ep: Disable PTM capabilities for EP mode
Dual mode DesignWare PCIe IP has PTM capability enabled (if supported) even in the EP mode. The PCIe compliance for the EP mode expects PTM c
PCI: designware-ep: Disable PTM capabilities for EP mode
Dual mode DesignWare PCIe IP has PTM capability enabled (if supported) even in the EP mode. The PCIe compliance for the EP mode expects PTM capabilities (ROOT_CAPABLE, RES_CAPABLE, CLK_GRAN) be disabled. Hence disable PTM for the EP mode.
Link: https://lore.kernel.org/r/20220919143340.4527-3-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Jingoo Han <jingoohan1@gmail.com>
show more ...
|
#
4284c88f |
| 22-Feb-2022 |
Frank Li <Frank.Li@nxp.com> |
PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address
ntb_mw_set_trans() will set memory map window after endpoint function driver bind. The inbound map address need be updated dyna
PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address
ntb_mw_set_trans() will set memory map window after endpoint function driver bind. The inbound map address need be updated dynamically when using NTB by PCIe Root Port and PCIe Endpoint connection.
Checking if iatu already assigned to the BAR, if yes, using assigned iatu number to update inbound address map and skip set BAR's register.
Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
show more ...
|
#
6be6f852 |
| 09-Jul-2022 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
PCI: dwc: Use the bitmap API to allocate bitmaps
Use devm_bitmap_zalloc() instead of hand-writing them.
It is less verbose and it improves the semantic.
Link: https://lore.kernel.org/r/bc6586a603a
PCI: dwc: Use the bitmap API to allocate bitmaps
Use devm_bitmap_zalloc() instead of hand-writing them.
It is less verbose and it improves the semantic.
Link: https://lore.kernel.org/r/bc6586a603abc0db7d4531308b698fbe7a6d7083.1657375829.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
ce06bf57 |
| 24-Jun-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Check iATU in/outbound range setup status
Make the DWC PCIe RC/EP safer and more verbose for invalid or failed inbound and outbound iATU window setups. Silently ignoring iATU regions setu
PCI: dwc: Check iATU in/outbound range setup status
Make the DWC PCIe RC/EP safer and more verbose for invalid or failed inbound and outbound iATU window setups. Silently ignoring iATU regions setup errors may cause unpredictable errors. For instance if a cfg or IO window fails to be activated, then any CFG/IO requested won't reach target PCIe devices and the corresponding accessors will return platform-specific random values.
[bhelgaas: trim commit log] Link: https://lore.kernel.org/r/20220624143947.8991-15-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
show more ...
|
#
38fe2723 |
| 24-Jun-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Drop enum dw_pcie_region_type in favor of PCIE_ATU_REGION_DIR_IB/OB
Previously callers of dw_pcie_disable_atu() supplied enum dw_pcie_region_type (DW_PCIE_REGION_INBOUND, DW_PCIE_REGION_OU
PCI: dwc: Drop enum dw_pcie_region_type in favor of PCIE_ATU_REGION_DIR_IB/OB
Previously callers of dw_pcie_disable_atu() supplied enum dw_pcie_region_type (DW_PCIE_REGION_INBOUND, DW_PCIE_REGION_OUTBOUND), which dw_pcie_disable_atu() converted to the PCIE_ATU_REGION_DIR_IB or PCIE_ATU_REGION_DIR_OB values needed to program the ATU registers.
Simplify the code by dropping the dw_pcie_region_type enum and passing PCIE_ATU_REGION_DIR_IB or PCIE_ATU_REGION_DIR_OB directly.
Reorder dw_pcie_disable_atu() arguments to (dir, index) since "index" indicates an ATU window in the regions of the corresponding direction.
[bhelgaas: commit log] Link: https://lore.kernel.org/r/20220624143947.8991-11-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
show more ...
|
#
4859db9b |
| 24-Jun-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Drop enum dw_pcie_as_type in favor of PCIE_ATU_TYPE_MEM/IO
Previously dw_pcie_ep_set_bar() converted the BAR PCI_BASE_ADDRESS_SPACE bit to the internal dw_pcie_as_type enum (DW_PCIE_AS_MEM
PCI: dwc: Drop enum dw_pcie_as_type in favor of PCIE_ATU_TYPE_MEM/IO
Previously dw_pcie_ep_set_bar() converted the BAR PCI_BASE_ADDRESS_SPACE bit to the internal dw_pcie_as_type enum (DW_PCIE_AS_MEM, DW_PCIE_AS_IO) and passed it down to dw_pcie_prog_inbound_atu(), which converted the enum to the PCIE_ATU_TYPE_MEM/PCIE_ATU_TYPE_IO values needed to program the ATU registers.
Simplify the code by dropping the dw_pcie_as_type enum and passing PCIE_ATU_TYPE_MEM or PCIE_ATU_TYPE_IO directly.
Reorder inbound ATU function arguments to match the outbound functions, with address-related parameters at the end.
[bhelgaas: commit log] Link: https://lore.kernel.org/r/20220624143947.8991-10-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
show more ...
|
#
13e9d390 |
| 24-Jun-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Read DWC IP core version from register
Since DWC PCIe v4.70a, the controller version and version type can be read from the PORT_LOGIC.PCIE_VERSION_OFF and PORT_LOGIC.PCIE_VERSION_TYPE_OFF
PCI: dwc: Read DWC IP core version from register
Since DWC PCIe v4.70a, the controller version and version type can be read from the PORT_LOGIC.PCIE_VERSION_OFF and PORT_LOGIC.PCIE_VERSION_TYPE_OFF registers respectively.
Read the version from those registers and warn if if's different from the version we got from the device tree.
We can only read the version after platform-specific drivers have done any DBI-related initialization, such as reference clock activation.
[bhelgaas: commit log] Link: https://lore.kernel.org/r/20220624143947.8991-5-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
show more ...
|
#
e3dc79ad |
| 24-Jun-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Detect iATU settings after getting "addr_space" resource
Previously, dw_pcie_ep_init() did:
dw_pcie_iatu_detect(pci); res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_sp
PCI: dwc: Detect iATU settings after getting "addr_space" resource
Previously, dw_pcie_ep_init() did:
dw_pcie_iatu_detect(pci); res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space"); if (!res) return -EINVAL;
The platform_get_resource_byname() can fail, and dw_pcie_iatu_detect() doesn't depend on the "addr_space" resource, so delay it until afterwards, i.e.,
platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space"); dw_pcie_iatu_detect(pci);
[bhelgaas: commit log] Link: https://lore.kernel.org/r/20220624143947.8991-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
show more ...
|
#
a37beefb |
| 24-Jun-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Add start_link/stop_link inlines
Factor out this pattern:
if (!pci->ops || !pci->ops->start_link) return -EINVAL;
return pci->ops->start_link(pci);
into a new dw_pcie_start_link
PCI: dwc: Add start_link/stop_link inlines
Factor out this pattern:
if (!pci->ops || !pci->ops->start_link) return -EINVAL;
return pci->ops->start_link(pci);
into a new dw_pcie_start_link() wrapper and do the same for the stop_link() method.
Note that dw_pcie_ep_start() previously returned -EINVAL if there was no platform start_link() method, which didn't make much sense since that is not an error. It will now return 0 in that case.
As a side-effect, drop the empty start_link() and dummy dw_pcie_ops instances from the generic DW PCIe and Layerscape EP platform drivers.
[bhelgaas: commit log] Link: https://lore.kernel.org/r/20220624143428.8334-14-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
show more ...
|
#
816f505f |
| 24-Jun-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Add braces to multi-line if-else statements
Add braces around single-line if-else statements when the opposite case requires them.
Link: https://lore.kernel.org/r/20220624143428.8334-8-Se
PCI: dwc: Add braces to multi-line if-else statements
Add braces around single-line if-else statements when the opposite case requires them.
Link: https://lore.kernel.org/r/20220624143428.8334-8-Sergey.Semin@baikalelectronics.ru Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org>
show more ...
|
#
8161e962 |
| 24-Jun-2022 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors
If dw_pcie_ep_init() fails to perform any action after the EPC memory is initialized and the MSI memory region is allocated, the latter pa
PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors
If dw_pcie_ep_init() fails to perform any action after the EPC memory is initialized and the MSI memory region is allocated, the latter parts won't be undone thus causing a memory leak. Add a cleanup-on-error path to fix these leaks.
[bhelgaas: commit log] Fixes: 2fd0c9d966cc ("PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init") Link: https://lore.kernel.org/r/20220624143428.8334-6-Sergey.Semin@baikalelectronics.ru Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
show more ...
|
#
f55fee56 |
| 20-Sep-2021 |
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> |
PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver
Add driver for Qualcomm PCIe Endpoint controller based on the DesignWare core with added Qualcomm-specific wrapper around the core. The dri
PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver
Add driver for Qualcomm PCIe Endpoint controller based on the DesignWare core with added Qualcomm-specific wrapper around the core. The driver support is very basic such that it supports only enumeration, PCIe read/write, and MSI. There is no ASPM and PM support for now but these will be added later.
The driver is capable of using the PERST# and WAKE# side-band GPIOs for operation and written on top of the DWC PCI framework.
[bhelgaas: wrap a few long lines] Co-developed-by: Siddartha Mohanadoss <smohanad@codeaurora.org> [mani: restructured the driver and fixed several bugs for upstream] Link: https://lore.kernel.org/r/20210920065946.15090-3-manivannan.sadhasivam@linaro.org Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org>
show more ...
|
#
53fd3cbe |
| 19-Aug-2021 |
Kishon Vijay Abraham I <kishon@ti.com> |
PCI: endpoint: Add virtual function number in pci_epc ops
Add virtual function number in pci_epc ops. EPC controller driver can perform virtual function specific initialization based on the virtual
PCI: endpoint: Add virtual function number in pci_epc ops
Add virtual function number in pci_epc ops. EPC controller driver can perform virtual function specific initialization based on the virtual function number.
Link: https://lore.kernel.org/r/20210819123343.1951-5-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
show more ...
|
#
8bcca265 |
| 13-Apr-2021 |
Hou Zhiqiang <Zhiqiang.Hou@nxp.com> |
PCI: dwc: Move iATU detection earlier
dw_pcie_ep_init() depends on the detected iATU region numbers to allocate the in/outbound window management bitmap. It fails after 281f1f99cf3a ("PCI: dwc: Det
PCI: dwc: Move iATU detection earlier
dw_pcie_ep_init() depends on the detected iATU region numbers to allocate the in/outbound window management bitmap. It fails after 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows").
Move the iATU region detection into a new function, move the detection to the very beginning of dw_pcie_host_init() and dw_pcie_ep_init(). Also remove it from the dw_pcie_setup(), since it's more like a software initialization step than hardware setup.
Link: https://lore.kernel.org/r/20210125044803.4310-1-Zhiqiang.Hou@nxp.com Link: https://lore.kernel.org/linux-pci/20210407131255.702054-1-dmitry.baryshkov@linaro.org Link: https://lore.kernel.org/r/20210413142219.2301430-1-dmitry.baryshkov@linaro.org Fixes: 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows") Tested-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> [DB: moved dw_pcie_iatu_detect to happen after host_init callback] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: stable@vger.kernel.org # v5.11+ Cc: Marek Szyprowski <m.szyprowski@samsung.com>
show more ...
|
#
a2f882d8 |
| 28-Jan-2021 |
Jisheng Zhang <Jisheng.Zhang@synaptics.com> |
PCI: dwc: Don't assume the ops in dw_pcie always exist
Some dwc-based device drivers, especially host-only drivers, may work well with the default read_dbi/write_dbi/link_up implementations in pcie-
PCI: dwc: Don't assume the ops in dw_pcie always exist
Some dwc-based device drivers, especially host-only drivers, may work well with the default read_dbi/write_dbi/link_up implementations in pcie-designware.c, so remove the assumption that every driver implements them to simplify those drivers.
Link: https://lore.kernel.org/r/20210128144258.10329aa4@xhacker.debian Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
281f1f99 |
| 05-Nov-2020 |
Rob Herring <robh@kernel.org> |
PCI: dwc: Detect number of iATU windows
Currently the number of inbound and outbound iATU windows are determined from DT properties. Unfortunately, there's 'num-viewport' for RC mode and 'num-ib-win
PCI: dwc: Detect number of iATU windows
Currently the number of inbound and outbound iATU windows are determined from DT properties. Unfortunately, there's 'num-viewport' for RC mode and 'num-ib-windows' and 'num-ob-windows' for EP mode, yet the number of windows is not mode dependent. Also, 'num-viewport' is not clear whether that's inbound, outbound or both. We can probably assume it's outbound windows as that's all RC mode uses.
However, using DT properties isn't really needed as the number of regions can be detected at runtime by poking the iATU registers. The basic algorithm is just writing a target address and reading back what we wrote. In the unrolled ATU case, we have to take care not to go past the mapped region.
With this, we can drop num_viewport in favor of num_ob_windows instead.
Link: https://lore.kernel.org/r/20201105211159.1814485-17-robh@kernel.org Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org
show more ...
|
#
9ca17af5 |
| 05-Nov-2020 |
Rob Herring <robh@kernel.org> |
PCI: dwc: Move inbound and outbound windows to common struct
The number of inbound and outbound windows are defined by the h/w and apply to both RC and EP modes, so move them to the appropriate stru
PCI: dwc: Move inbound and outbound windows to common struct
The number of inbound and outbound windows are defined by the h/w and apply to both RC and EP modes, so move them to the appropriate struct.
Link: https://lore.kernel.org/r/20201105211159.1814485-16-robh@kernel.org Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
a0fd361d |
| 05-Nov-2020 |
Rob Herring <robh@kernel.org> |
PCI: dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common code
Most DWC drivers use the common register resource names "dbi", "dbi2", and "addr_space", so let's move their setup into
PCI: dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common code
Most DWC drivers use the common register resource names "dbi", "dbi2", and "addr_space", so let's move their setup into the DWC common code.
This means 'dbi_base' in particular is setup later, but it looks like no drivers touch DBI registers before dw_pcie_host_init or dw_pcie_ep_init.
Link: https://lore.kernel.org/r/20201105211159.1814485-4-robh@kernel.org Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Jingoo Han <jingoohan1@gmail.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: Minghuan Lian <minghuan.Lian@nxp.com> Cc: Mingkai Hu <mingkai.hu@nxp.com> Cc: Roy Zang <roy.zang@nxp.com> Cc: Jonathan Chocron <jonnyc@amazon.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Xiaowei Song <songxiaowei@hisilicon.com> Cc: Binghui Wang <wangbinghui@hisilicon.com> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Stanimir Varbanov <svarbanov@mm-sol.com> Cc: Pratyush Anand <pratyush.anand@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: linux-omap@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-arm-kernel@axis.com Cc: linux-arm-msm@vger.kernel.org Cc: linux-tegra@vger.kernel.org
show more ...
|