History log of /openbmc/linux/drivers/pci/controller/dwc/pcie-designware-ep.c (Results 1 – 25 of 57)
Revision Date Author Comments
# 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 ...


123