Hello all!
Working in close co-operation with Pali we made an initial attempt at bringing
support for orion PCIe into mvebu PCIe driver. Currently the address of
workaround memory range is hard coded and based on compatible string only. As
Pali describes in another thread, we were not able to figure out what's the
correct way to configure a configuration space. That discussion is here:
https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u
I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
comments and feedback is welcome.
Thanks,
Mauri
Mauri Sandberg (2):
dt-bindings: PCI: mvebu: Add orion5x compatible
PCI: mvebu: add support for orion5x
.../devicetree/bindings/pci/mvebu-pci.txt | 1 +
arch/arm/mach-orion5x/common.c | 13 ----
drivers/pci/controller/Kconfig | 2 +-
drivers/pci/controller/pci-mvebu.c | 59 +++++++++++++++++++
4 files changed, 61 insertions(+), 14 deletions(-)
base-commit: ff6992735ade75aae3e35d16b17da1008d753d28
--
2.25.1
Add a compatible string to bindings to indicate that orion5x PCIe is
supported too.
Signed-off-by: Mauri Sandberg <[email protected]>
---
Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6d022a9d36ee..ced5d030fe55 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -7,6 +7,7 @@ Mandatory properties:
marvell,armada-xp-pcie
marvell,dove-pcie
marvell,kirkwood-pcie
+ marvell,orion5x-pcie
- #address-cells, set to <3>
- #size-cells, set to <2>
- #interrupt-cells, set to <1>
--
2.25.1
Add a compatible string to bindings to indicate that orion5x PCIe is
supported too.
Signed-off-by: Mauri Sandberg <[email protected]>
---
Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6d022a9d36ee..ced5d030fe55 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -7,6 +7,7 @@ Mandatory properties:
marvell,armada-xp-pcie
marvell,dove-pcie
marvell,kirkwood-pcie
+ marvell,orion5x-pcie
- #address-cells, set to <3>
- #size-cells, set to <2>
- #interrupt-cells, set to <1>
--
2.25.1
On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <[email protected]> wrote:
>
> Hello all!
>
> Working in close co-operation with Pali we made an initial attempt at bringing
> support for orion PCIe into mvebu PCIe driver. Currently the address of
> workaround memory range is hard coded and based on compatible string only. As
> Pali describes in another thread, we were not able to figure out what's the
> correct way to configure a configuration space. That discussion is here:
> https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u
>
> I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
> comments and feedback is welcome.
Hi Mauri,
I've managed to dig out my old series for reworking the orion5x PCI/PCIe
support, to the point where the two drivers are completely independent.
Please have a look at
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=orion-pci-cleanup
to see if this helps you at all. I see now that your DNS-323 only supports
PCIe but not PCI, so maybe it's not all that helpful for your machine,
but it should help for converting the other ones that do use legacy
PCI and want to base DT support on top of this work.
Arnd
On Mon, 18 Jul 2022 23:28:41 +0300, Mauri Sandberg wrote:
> Add a compatible string to bindings to indicate that orion5x PCIe is
> supported too.
>
> Signed-off-by: Mauri Sandberg <[email protected]>
> ---
> Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <[email protected]>
On Mon, Jul 18, 2022 at 11:28:40PM +0300, Mauri Sandberg wrote:
> Hello all!
>
> Working in close co-operation with Pali we made an initial attempt at bringing
> support for orion PCIe into mvebu PCIe driver. Currently the address of
> workaround memory range is hard coded and based on compatible string only. As
> Pali describes in another thread, we were not able to figure out what's the
> correct way to configure a configuration space. That discussion is here:
> https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u
>
> I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
> comments and feedback is welcome.
>
> Thanks,
> Mauri
>
> Mauri Sandberg (2):
> dt-bindings: PCI: mvebu: Add orion5x compatible
> PCI: mvebu: add support for orion5x
>
> .../devicetree/bindings/pci/mvebu-pci.txt | 1 +
> arch/arm/mach-orion5x/common.c | 13 ----
> drivers/pci/controller/Kconfig | 2 +-
> drivers/pci/controller/pci-mvebu.c | 59 +++++++++++++++++++
> 4 files changed, 61 insertions(+), 14 deletions(-)
Hi Mauri,
Can you address anything in 2/2 (if necessary), incorporate any acks,
and post a v2? There was some confusion around the first patch (there
are two in the thread, likely the same?), and I didn't read the 2/2
feedback in detail to see if any changes were needed.
Bjorn
Hi Bjorn!
On 29.07.22 20:22, Bjorn Helgaas wrote:
> On Mon, Jul 18, 2022 at 11:28:40PM +0300, Mauri Sandberg wrote:
>> Hello all!
>>
>> Working in close co-operation with Pali we made an initial attempt at bringing
>> support for orion PCIe into mvebu PCIe driver. Currently the address of
>> workaround memory range is hard coded and based on compatible string only. As
>> Pali describes in another thread, we were not able to figure out what's the
>> correct way to configure a configuration space. That discussion is here:
>> https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u
>>
>> I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
>> comments and feedback is welcome.
>>
>> Thanks,
>> Mauri
>>
>> Mauri Sandberg (2):
>> dt-bindings: PCI: mvebu: Add orion5x compatible
>> PCI: mvebu: add support for orion5x
>>
>> .../devicetree/bindings/pci/mvebu-pci.txt | 1 +
>> arch/arm/mach-orion5x/common.c | 13 ----
>> drivers/pci/controller/Kconfig | 2 +-
>> drivers/pci/controller/pci-mvebu.c | 59 +++++++++++++++++++
>> 4 files changed, 61 insertions(+), 14 deletions(-)
>
> Hi Mauri,
>
> Can you address anything in 2/2 (if necessary), incorporate any acks,
> and post a v2? There was some confusion around the first patch (there
> are two in the thread, likely the same?), and I didn't read the 2/2
> feedback in detail to see if any changes were needed.
>
I give it a little bit time to see if the discussion on how to configure
the configuration space would pick up, but I'll attend to the comments
and post a clean v2 soonish.
Hello all,
Here a cleaned up version of the previous series.
Changes
- instead of removing PCIe related mvebu windows add them in pcie_setup()
I intentionally left the ORION5X_PCIE_WA_VIRT_BASE in place as all pieces
in the puzzle have not found their place yet. It will be replaced with
ioremap() or similar when the problem of passing the address to
configuration space from a device tree is solved.
Tested with DNS323 both DT and non-DT builds.
Thanks,
Mauri
Mauri Sandberg (2):
dt-bindings: PCI: mvebu: Add orion5x compatible
PCI: mvebu: add support for orion5x
.../devicetree/bindings/pci/mvebu-pci.txt | 1 +
arch/arm/mach-orion5x/common.c | 13 ----
arch/arm/mach-orion5x/pci.c | 14 +++++
drivers/pci/controller/Kconfig | 2 +-
drivers/pci/controller/pci-mvebu.c | 59 +++++++++++++++++++
5 files changed, 75 insertions(+), 14 deletions(-)
base-commit: 7d0d3fa7339ed5a06d6608b7cde9f079eba62bb1
--
2.25.1
On Tuesday 02 August 2022 20:34:21 Mauri Sandberg wrote:
> Hello all,
>
> Here a cleaned up version of the previous series.
>
> Changes
> - instead of removing PCIe related mvebu windows add them in pcie_setup()
>
> I intentionally left the ORION5X_PCIE_WA_VIRT_BASE in place as all pieces
> in the puzzle have not found their place yet. It will be replaced with
> ioremap() or similar when the problem of passing the address to
> configuration space from a device tree is solved.
Hello all, could you please look at the issue how to write
representation of PCIe config space in device tree?
https://lore.kernel.org/linux-devicetree/20220710225108.bgedria6igtqpz5l@pali/
Without it we cannot finish this conversion of orion5x pcie code from
arch/arm to pci-mvebu.c
> Tested with DNS323 both DT and non-DT builds.
>
> Thanks,
> Mauri
>
> Mauri Sandberg (2):
> dt-bindings: PCI: mvebu: Add orion5x compatible
> PCI: mvebu: add support for orion5x
>
> .../devicetree/bindings/pci/mvebu-pci.txt | 1 +
> arch/arm/mach-orion5x/common.c | 13 ----
> arch/arm/mach-orion5x/pci.c | 14 +++++
> drivers/pci/controller/Kconfig | 2 +-
> drivers/pci/controller/pci-mvebu.c | 59 +++++++++++++++++++
> 5 files changed, 75 insertions(+), 14 deletions(-)
>
>
> base-commit: 7d0d3fa7339ed5a06d6608b7cde9f079eba62bb1
> --
> 2.25.1
Add support for orion5x PCIe controller.
There is Orion-specific errata that config space via CF8/CFC registers
is broken. Workaround documented in errata documented (linked from above
documentation) does not work when DMA is used and instead other
undocumented workaround is needed which maps config space to memory
(and therefore avoids usage of broken CF8/CFC memory mapped registers).
Signed-off-by: Mauri Sandberg <[email protected]>
Cc: Pali Rohár <[email protected]>
---
v1 -> v2:
- do pcie related mvebu windows and remaps in pcie_setup()
---
arch/arm/mach-orion5x/common.c | 13 -------
arch/arm/mach-orion5x/pci.c | 14 +++++++
drivers/pci/controller/Kconfig | 2 +-
drivers/pci/controller/pci-mvebu.c | 59 ++++++++++++++++++++++++++++++
4 files changed, 74 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 7bcb41137bbf..9d8be5ce1266 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
void orion5x_setup_wins(void)
{
- /*
- * The PCIe windows will no longer be statically allocated
- * here once Orion5x is migrated to the pci-mvebu driver.
- */
- mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
- ORION_MBUS_PCIE_IO_ATTR,
- ORION5X_PCIE_IO_PHYS_BASE,
- ORION5X_PCIE_IO_SIZE,
- ORION5X_PCIE_IO_BUS_BASE);
- mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
- ORION_MBUS_PCIE_MEM_ATTR,
- ORION5X_PCIE_MEM_PHYS_BASE,
- ORION5X_PCIE_MEM_SIZE);
mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
ORION_MBUS_PCI_IO_ATTR,
ORION5X_PCI_IO_PHYS_BASE,
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 9574c73f3c03..7c4e2f355cc7 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -150,6 +150,20 @@ static int __init pcie_setup(struct pci_sys_data *sys)
*/
orion_pcie_setup(PCIE_BASE);
+ /*
+ * The PCIe windows will no longer be statically allocated
+ * here once Orion5x is migrated to the pci-mvebu driver.
+ */
+ mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+ ORION_MBUS_PCIE_IO_ATTR,
+ ORION5X_PCIE_IO_PHYS_BASE,
+ ORION5X_PCIE_IO_SIZE,
+ ORION5X_PCIE_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+ ORION_MBUS_PCIE_MEM_ATTR,
+ ORION5X_PCIE_MEM_PHYS_BASE,
+ ORION5X_PCIE_MEM_SIZE);
+
/*
* Check whether to apply Orion-1/Orion-NAS PCIe config
* read transaction workaround.
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index b8d96d38064d..a249375837f0 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -5,7 +5,7 @@ menu "PCI controller drivers"
config PCI_MVEBU
tristate "Marvell EBU PCIe controller"
- depends on ARCH_MVEBU || ARCH_DOVE || COMPILE_TEST
+ depends on ARCH_MVEBU || ARCH_DOVE || ARCH_ORION5X || COMPILE_TEST
depends on MVEBU_MBUS
depends on ARM
depends on OF
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index c1ffdb06c971..1d3052aa7e49 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1487,6 +1487,54 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
return 0;
}
+static int orion_pcie_rd_conf_wa(void __iomem *wa_base, struct pci_bus *bus,
+ u32 devfn, int where, int size, u32 *val)
+{
+ *val = readl(wa_base + (PCIE_CONF_BUS(bus->number) |
+ PCIE_CONF_DEV(PCI_SLOT(devfn)) |
+ PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
+ PCIE_CONF_REG(where)));
+
+ if (size == 1)
+ *val = (*val >> (8 * (where & 3))) & 0xff;
+ else if (size == 2)
+ *val = (*val >> (8 * (where & 3))) & 0xffff;
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+/* Relevant only for Orion-1/Orion-NAS */
+#define ORION5X_PCIE_WA_PHYS_BASE 0xf0000000
+#define ORION5X_PCIE_WA_VIRT_BASE IOMEM(0xfd000000)
+#define ORION5X_PCIE_WA_SIZE SZ_16M
+#define ORION_MBUS_PCIE_WA_TARGET 0x04
+#define ORION_MBUS_PCIE_WA_ATTR 0x79
+
+static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
+{
+ struct mvebu_pcie *pcie = bus->sysdata;
+ struct mvebu_pcie_port *port;
+
+ port = mvebu_pcie_find_port(pcie, bus, devfn);
+ if (!port)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (!mvebu_pcie_link_up(port))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ /*
+ * We only support access to the non-extended configuration
+ * space when using the WA access method (or we would have to
+ * sacrifice 256M of CPU virtual address space.)
+ */
+ if (where >= 0x100) {
+ *val = 0xffffffff;
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ }
+
+ return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
+}
+
static int mvebu_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1663,6 +1711,16 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
bridge->align_resource = mvebu_pcie_align_resource;
bridge->map_irq = mvebu_pcie_map_irq;
+ if (of_machine_is_compatible("marvell,orion5x-88f5181")) {
+ dev_info(dev, "Applying Orion-1/Orion-NAS PCIe config read transaction workaround\n");
+
+ mvebu_pcie_child_ops.read = mvebu_pcie_child_rd_conf_wa;
+ mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
+ ORION_MBUS_PCIE_WA_ATTR,
+ ORION5X_PCIE_WA_PHYS_BASE,
+ ORION5X_PCIE_WA_SIZE);
+ }
+
return pci_host_probe(bridge);
}
@@ -1733,6 +1791,7 @@ static const struct of_device_id mvebu_pcie_of_match_table[] = {
{ .compatible = "marvell,armada-370-pcie", },
{ .compatible = "marvell,dove-pcie", },
{ .compatible = "marvell,kirkwood-pcie", },
+ { .compatible = "marvell,orion5x-pcie", },
{},
};
--
2.25.1
On Tue, Aug 02, 2022 at 08:34:23PM +0300, Mauri Sandberg wrote:
> Add support for orion5x PCIe controller.
>
> There is Orion-specific errata that config space via CF8/CFC registers
> is broken. Workaround documented in errata documented (linked from above
> documentation) does not work when DMA is used and instead other
Linked to which documentation ?
> undocumented workaround is needed which maps config space to memory
> (and therefore avoids usage of broken CF8/CFC memory mapped registers).
>
> Signed-off-by: Mauri Sandberg <[email protected]>
> Cc: Pali Roh?r <[email protected]>
> ---
> v1 -> v2:
> - do pcie related mvebu windows and remaps in pcie_setup()
> ---
> arch/arm/mach-orion5x/common.c | 13 -------
> arch/arm/mach-orion5x/pci.c | 14 +++++++
> drivers/pci/controller/Kconfig | 2 +-
> drivers/pci/controller/pci-mvebu.c | 59 ++++++++++++++++++++++++++++++
> 4 files changed, 74 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
> index 7bcb41137bbf..9d8be5ce1266 100644
> --- a/arch/arm/mach-orion5x/common.c
> +++ b/arch/arm/mach-orion5x/common.c
> @@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
>
> void orion5x_setup_wins(void)
> {
> - /*
> - * The PCIe windows will no longer be statically allocated
> - * here once Orion5x is migrated to the pci-mvebu driver.
> - */
> - mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> - ORION_MBUS_PCIE_IO_ATTR,
> - ORION5X_PCIE_IO_PHYS_BASE,
> - ORION5X_PCIE_IO_SIZE,
> - ORION5X_PCIE_IO_BUS_BASE);
> - mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> - ORION_MBUS_PCIE_MEM_ATTR,
> - ORION5X_PCIE_MEM_PHYS_BASE,
> - ORION5X_PCIE_MEM_SIZE);
> mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
> ORION_MBUS_PCI_IO_ATTR,
> ORION5X_PCI_IO_PHYS_BASE,
> diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
> index 9574c73f3c03..7c4e2f355cc7 100644
> --- a/arch/arm/mach-orion5x/pci.c
> +++ b/arch/arm/mach-orion5x/pci.c
> @@ -150,6 +150,20 @@ static int __init pcie_setup(struct pci_sys_data *sys)
> */
> orion_pcie_setup(PCIE_BASE);
>
> + /*
> + * The PCIe windows will no longer be statically allocated
> + * here once Orion5x is migrated to the pci-mvebu driver.
> + */
Is this comment still relevant ? And more importantly, may I ask
you why this code move in this hunk ? I think, whatever the reason
is, that deserves a comment.
> + mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> + ORION_MBUS_PCIE_IO_ATTR,
> + ORION5X_PCIE_IO_PHYS_BASE,
> + ORION5X_PCIE_IO_SIZE,
> + ORION5X_PCIE_IO_BUS_BASE);
> + mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> + ORION_MBUS_PCIE_MEM_ATTR,
> + ORION5X_PCIE_MEM_PHYS_BASE,
> + ORION5X_PCIE_MEM_SIZE);
> +
> /*
> * Check whether to apply Orion-1/Orion-NAS PCIe config
> * read transaction workaround.
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index b8d96d38064d..a249375837f0 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -5,7 +5,7 @@ menu "PCI controller drivers"
>
> config PCI_MVEBU
> tristate "Marvell EBU PCIe controller"
> - depends on ARCH_MVEBU || ARCH_DOVE || COMPILE_TEST
> + depends on ARCH_MVEBU || ARCH_DOVE || ARCH_ORION5X || COMPILE_TEST
> depends on MVEBU_MBUS
> depends on ARM
> depends on OF
> diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
> index c1ffdb06c971..1d3052aa7e49 100644
> --- a/drivers/pci/controller/pci-mvebu.c
> +++ b/drivers/pci/controller/pci-mvebu.c
> @@ -1487,6 +1487,54 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
> return 0;
> }
>
> +static int orion_pcie_rd_conf_wa(void __iomem *wa_base, struct pci_bus *bus,
> + u32 devfn, int where, int size, u32 *val)
> +{
> + *val = readl(wa_base + (PCIE_CONF_BUS(bus->number) |
> + PCIE_CONF_DEV(PCI_SLOT(devfn)) |
> + PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
> + PCIE_CONF_REG(where)));
> +
> + if (size == 1)
> + *val = (*val >> (8 * (where & 3))) & 0xff;
> + else if (size == 2)
> + *val = (*val >> (8 * (where & 3))) & 0xffff;
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +/* Relevant only for Orion-1/Orion-NAS */
> +#define ORION5X_PCIE_WA_PHYS_BASE 0xf0000000
> +#define ORION5X_PCIE_WA_VIRT_BASE IOMEM(0xfd000000)
> +#define ORION5X_PCIE_WA_SIZE SZ_16M
> +#define ORION_MBUS_PCIE_WA_TARGET 0x04
> +#define ORION_MBUS_PCIE_WA_ATTR 0x79
> +
> +static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
> +{
> + struct mvebu_pcie *pcie = bus->sysdata;
> + struct mvebu_pcie_port *port;
> +
> + port = mvebu_pcie_find_port(pcie, bus, devfn);
> + if (!port)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +
> + if (!mvebu_pcie_link_up(port))
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +
> + /*
> + * We only support access to the non-extended configuration
> + * space when using the WA access method (or we would have to
> + * sacrifice 256M of CPU virtual address space.)
Please expand the comment - future reviewers and developers may need
this information to understand this choice, me included.
Lorenzo
> + */
> + if (where >= 0x100) {
> + *val = 0xffffffff;
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + }
> +
> + return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
> +}
> +
> static int mvebu_pcie_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -1663,6 +1711,16 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
> bridge->align_resource = mvebu_pcie_align_resource;
> bridge->map_irq = mvebu_pcie_map_irq;
>
> + if (of_machine_is_compatible("marvell,orion5x-88f5181")) {
> + dev_info(dev, "Applying Orion-1/Orion-NAS PCIe config read transaction workaround\n");
> +
> + mvebu_pcie_child_ops.read = mvebu_pcie_child_rd_conf_wa;
> + mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
> + ORION_MBUS_PCIE_WA_ATTR,
> + ORION5X_PCIE_WA_PHYS_BASE,
> + ORION5X_PCIE_WA_SIZE);
> + }
> +
> return pci_host_probe(bridge);
> }
>
> @@ -1733,6 +1791,7 @@ static const struct of_device_id mvebu_pcie_of_match_table[] = {
> { .compatible = "marvell,armada-370-pcie", },
> { .compatible = "marvell,dove-pcie", },
> { .compatible = "marvell,kirkwood-pcie", },
> + { .compatible = "marvell,orion5x-pcie", },
> {},
> };
>
> --
> 2.25.1
>
On Thursday 25 August 2022 17:15:36 Lorenzo Pieralisi wrote:
> On Tue, Aug 02, 2022 at 08:34:23PM +0300, Mauri Sandberg wrote:
> > Add support for orion5x PCIe controller.
> >
> > There is Orion-specific errata that config space via CF8/CFC registers
> > is broken. Workaround documented in errata documented (linked from above
> > documentation) does not work when DMA is used and instead other
>
> Linked to which documentation ?
Hello! Orion Errata document is linked from kernel doc:
https://www.kernel.org/doc/html/latest/arm/marvell.html
On Thu, Aug 25, 2022 at 06:00:51PM +0200, Pali Roh?r wrote:
> On Thursday 25 August 2022 17:15:36 Lorenzo Pieralisi wrote:
> > On Tue, Aug 02, 2022 at 08:34:23PM +0300, Mauri Sandberg wrote:
> > > Add support for orion5x PCIe controller.
> > >
> > > There is Orion-specific errata that config space via CF8/CFC registers
> > > is broken. Workaround documented in errata documented (linked from above
> > > documentation) does not work when DMA is used and instead other
> >
> > Linked to which documentation ?
>
> Hello! Orion Errata document is linked from kernel doc:
> https://www.kernel.org/doc/html/latest/arm/marvell.html
Add a Link: tag to the patch, thanks.
Lorenzo
Hello! This patch series add support for Orion PCIe controller into
pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
to parse all physical addresses from device tree files according to
mvebu-pci.txt documentation, allow access to all extended PCIe config
space registers and use modern kernel API pci_remap_cfgspace() and
mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
there because this change and it is de-facto API between dts files and
kernel used for a long time. Note that it is misused according to PCI
device tree bindings, but we have to follow this Marvell bindings to do
not introduce backward incompatibility issues for other non-Orion
platforms.
Mauri tested these changes on DNS323 board with both DT and non-DT builds.
PCIe AER is working too (one of the feature which proved that access to
extended PCIe config registers is working fine).
After this patch is accepted we are planning to look at existing Orion
arch specific code and covert it to use this new DT based pci-mvebu.c
code. Later this would allow to kill arch specific Orion PCIe code,
which is in arch/arm/plat-orion/pcie.c and parts also in file
arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
This patch series depends on another patches:
https://lore.kernel.org/linux-pci/[email protected]/
https://lore.kernel.org/linux-pci/[email protected]/
Mauri Sandberg (2):
bus: mvebu-mbus: add configuration space aperture
dt-bindings: PCI: mvebu: Add orion5x compatible
Pali Rohár (5):
ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
pcie_setup()
PCI: mvebu: Remove unused busn member
PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
PCI: mvebu: Add support for Orion PCIe controller
ARM: dts: orion5x: Add PCIe node
.../devicetree/bindings/pci/mvebu-pci.txt | 4 +-
arch/arm/boot/dts/orion5x.dtsi | 51 +++++
arch/arm/mach-orion5x/common.c | 13 --
arch/arm/mach-orion5x/pci.c | 14 ++
drivers/bus/mvebu-mbus.c | 26 ++-
drivers/pci/controller/Kconfig | 4 +-
drivers/pci/controller/pci-mvebu.c | 202 ++++++++++++++----
include/linux/mbus.h | 1 +
8 files changed, 256 insertions(+), 59 deletions(-)
--
2.20.1
Signed-off-by: Pali Rohár <[email protected]>
---
Changes in v3:
* New patch
---
drivers/pci/controller/pci-mvebu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 6ef8c1ee4cbb..d9e46bd7a4ec 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -96,7 +96,6 @@ struct mvebu_pcie {
struct resource io;
struct resource realio;
struct resource mem;
- struct resource busn;
int nports;
};
--
2.20.1
This would allow to migrate Orion PCIe code to pci-mvebu.c driver as this
driver reads mapping information from device tree files and does not relay
on static mappings.
Signed-off-by: Pali Rohár <[email protected]>
---
Changes in v3:
* Split it from pci-mvebu.c change to separate patch
---
arch/arm/mach-orion5x/common.c | 13 -------------
arch/arm/mach-orion5x/pci.c | 14 ++++++++++++++
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 2e711b7252c6..df5e7b237946 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -228,19 +228,6 @@ void __init orion5x_init_early(void)
void orion5x_setup_wins(void)
{
- /*
- * The PCIe windows will no longer be statically allocated
- * here once Orion5x is migrated to the pci-mvebu driver.
- */
- mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
- ORION_MBUS_PCIE_IO_ATTR,
- ORION5X_PCIE_IO_PHYS_BASE,
- ORION5X_PCIE_IO_SIZE,
- ORION5X_PCIE_IO_BUS_BASE);
- mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
- ORION_MBUS_PCIE_MEM_ATTR,
- ORION5X_PCIE_MEM_PHYS_BASE,
- ORION5X_PCIE_MEM_SIZE);
mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
ORION_MBUS_PCI_IO_ATTR,
ORION5X_PCI_IO_PHYS_BASE,
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 888fdc9099c5..e0836be92f3f 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -147,6 +147,20 @@ static int __init pcie_setup(struct pci_sys_data *sys)
*/
orion_pcie_setup(PCIE_BASE);
+ /*
+ * The PCIe windows will no longer be statically allocated
+ * here once Orion5x is migrated to the pci-mvebu driver.
+ */
+ mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+ ORION_MBUS_PCIE_IO_ATTR,
+ ORION5X_PCIE_IO_PHYS_BASE,
+ ORION5X_PCIE_IO_SIZE,
+ ORION5X_PCIE_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+ ORION_MBUS_PCIE_MEM_ATTR,
+ ORION5X_PCIE_MEM_PHYS_BASE,
+ ORION5X_PCIE_MEM_SIZE);
+
/*
* Check whether to apply Orion-1/Orion-NAS PCIe config
* read transaction workaround.
--
2.20.1
On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Roh?r wrote:
> Hello! This patch series add support for Orion PCIe controller into
> pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> to parse all physical addresses from device tree files according to
> mvebu-pci.txt documentation, allow access to all extended PCIe config
> space registers and use modern kernel API pci_remap_cfgspace() and
> mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
>
> Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> there because this change and it is de-facto API between dts files and
> kernel used for a long time. Note that it is misused according to PCI
> device tree bindings, but we have to follow this Marvell bindings to do
> not introduce backward incompatibility issues for other non-Orion
> platforms.
>
> Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> PCIe AER is working too (one of the feature which proved that access to
> extended PCIe config registers is working fine).
>
> After this patch is accepted we are planning to look at existing Orion
> arch specific code and covert it to use this new DT based pci-mvebu.c
> code. Later this would allow to kill arch specific Orion PCIe code,
> which is in arch/arm/plat-orion/pcie.c and parts also in file
> arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
>
> This patch series depends on another patches:
> https://lore.kernel.org/linux-pci/[email protected]/
> https://lore.kernel.org/linux-pci/[email protected]/
Can I rebase it on top of v6.0-rc1 ? I will not be able to pull it till
-rc7 but I don't think there is a strict dependency so we should try to
upstream it this cycle.
Lorenzo
>
> Mauri Sandberg (2):
> bus: mvebu-mbus: add configuration space aperture
> dt-bindings: PCI: mvebu: Add orion5x compatible
>
> Pali Roh?r (5):
> ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> pcie_setup()
> PCI: mvebu: Remove unused busn member
> PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> PCI: mvebu: Add support for Orion PCIe controller
> ARM: dts: orion5x: Add PCIe node
>
> .../devicetree/bindings/pci/mvebu-pci.txt | 4 +-
> arch/arm/boot/dts/orion5x.dtsi | 51 +++++
> arch/arm/mach-orion5x/common.c | 13 --
> arch/arm/mach-orion5x/pci.c | 14 ++
> drivers/bus/mvebu-mbus.c | 26 ++-
> drivers/pci/controller/Kconfig | 4 +-
> drivers/pci/controller/pci-mvebu.c | 202 ++++++++++++++----
> include/linux/mbus.h | 1 +
> 8 files changed, 256 insertions(+), 59 deletions(-)
>
> --
> 2.20.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Roh?r wrote:
> Hello! This patch series add support for Orion PCIe controller into
> pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> to parse all physical addresses from device tree files according to
> mvebu-pci.txt documentation, allow access to all extended PCIe config
> space registers and use modern kernel API pci_remap_cfgspace() and
> mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
>
> Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> there because this change and it is de-facto API between dts files and
> kernel used for a long time. Note that it is misused according to PCI
> device tree bindings, but we have to follow this Marvell bindings to do
> not introduce backward incompatibility issues for other non-Orion
> platforms.
>
> Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> PCIe AER is working too (one of the feature which proved that access to
> extended PCIe config registers is working fine).
>
> After this patch is accepted we are planning to look at existing Orion
> arch specific code and covert it to use this new DT based pci-mvebu.c
> code. Later this would allow to kill arch specific Orion PCIe code,
> which is in arch/arm/plat-orion/pcie.c and parts also in file
> arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
>
> This patch series depends on another patches:
> https://lore.kernel.org/linux-pci/[email protected]/
> https://lore.kernel.org/linux-pci/[email protected]/
Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?
Thanks,
Lorenzo
> Mauri Sandberg (2):
> bus: mvebu-mbus: add configuration space aperture
> dt-bindings: PCI: mvebu: Add orion5x compatible
>
> Pali Roh?r (5):
> ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> pcie_setup()
> PCI: mvebu: Remove unused busn member
> PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> PCI: mvebu: Add support for Orion PCIe controller
> ARM: dts: orion5x: Add PCIe node
>
> .../devicetree/bindings/pci/mvebu-pci.txt | 4 +-
> arch/arm/boot/dts/orion5x.dtsi | 51 +++++
> arch/arm/mach-orion5x/common.c | 13 --
> arch/arm/mach-orion5x/pci.c | 14 ++
> drivers/bus/mvebu-mbus.c | 26 ++-
> drivers/pci/controller/Kconfig | 4 +-
> drivers/pci/controller/pci-mvebu.c | 202 ++++++++++++++----
> include/linux/mbus.h | 1 +
> 8 files changed, 256 insertions(+), 59 deletions(-)
>
> --
> 2.20.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Thursday 27 October 2022 16:10:48 Lorenzo Pieralisi wrote:
> On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> > Hello! This patch series add support for Orion PCIe controller into
> > pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> > to parse all physical addresses from device tree files according to
> > mvebu-pci.txt documentation, allow access to all extended PCIe config
> > space registers and use modern kernel API pci_remap_cfgspace() and
> > mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> >
> > Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> > there because this change and it is de-facto API between dts files and
> > kernel used for a long time. Note that it is misused according to PCI
> > device tree bindings, but we have to follow this Marvell bindings to do
> > not introduce backward incompatibility issues for other non-Orion
> > platforms.
> >
> > Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> > PCIe AER is working too (one of the feature which proved that access to
> > extended PCIe config registers is working fine).
> >
> > After this patch is accepted we are planning to look at existing Orion
> > arch specific code and covert it to use this new DT based pci-mvebu.c
> > code. Later this would allow to kill arch specific Orion PCIe code,
> > which is in arch/arm/plat-orion/pcie.c and parts also in file
> > arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> >
> > This patch series depends on another patches:
> > https://lore.kernel.org/linux-pci/[email protected]/
> > https://lore.kernel.org/linux-pci/[email protected]/
>
> Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?
IIRC above two dependent patches still applies on master branch and this
patch series applies on above two dependent patches.
> Thanks,
> Lorenzo
>
> > Mauri Sandberg (2):
> > bus: mvebu-mbus: add configuration space aperture
> > dt-bindings: PCI: mvebu: Add orion5x compatible
> >
> > Pali Rohár (5):
> > ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> > pcie_setup()
> > PCI: mvebu: Remove unused busn member
> > PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> > PCI: mvebu: Add support for Orion PCIe controller
> > ARM: dts: orion5x: Add PCIe node
> >
> > .../devicetree/bindings/pci/mvebu-pci.txt | 4 +-
> > arch/arm/boot/dts/orion5x.dtsi | 51 +++++
> > arch/arm/mach-orion5x/common.c | 13 --
> > arch/arm/mach-orion5x/pci.c | 14 ++
> > drivers/bus/mvebu-mbus.c | 26 ++-
> > drivers/pci/controller/Kconfig | 4 +-
> > drivers/pci/controller/pci-mvebu.c | 202 ++++++++++++++----
> > include/linux/mbus.h | 1 +
> > 8 files changed, 256 insertions(+), 59 deletions(-)
> >
> > --
> > 2.20.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Nov 07, 2022 at 12:28:24AM +0100, Pali Roh?r wrote:
> On Thursday 27 October 2022 16:10:48 Lorenzo Pieralisi wrote:
> > On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Roh?r wrote:
> > > Hello! This patch series add support for Orion PCIe controller into
> > > pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> > > to parse all physical addresses from device tree files according to
> > > mvebu-pci.txt documentation, allow access to all extended PCIe config
> > > space registers and use modern kernel API pci_remap_cfgspace() and
> > > mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> > >
> > > Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> > > there because this change and it is de-facto API between dts files and
> > > kernel used for a long time. Note that it is misused according to PCI
> > > device tree bindings, but we have to follow this Marvell bindings to do
> > > not introduce backward incompatibility issues for other non-Orion
> > > platforms.
> > >
> > > Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> > > PCIe AER is working too (one of the feature which proved that access to
> > > extended PCIe config registers is working fine).
> > >
> > > After this patch is accepted we are planning to look at existing Orion
> > > arch specific code and covert it to use this new DT based pci-mvebu.c
> > > code. Later this would allow to kill arch specific Orion PCIe code,
> > > which is in arch/arm/plat-orion/pcie.c and parts also in file
> > > arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> > >
> > > This patch series depends on another patches:
> > > https://lore.kernel.org/linux-pci/[email protected]/
> > > https://lore.kernel.org/linux-pci/[email protected]/
> >
> > Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?
>
> IIRC above two dependent patches still applies on master branch and this
> patch series applies on above two dependent patches.
Which I can't merge for reasons you are aware of already.
So, does this series _really_ depend on the two patches above ?
I don't think so but let me ask again.
Lorenzo
> > Thanks,
> > Lorenzo
> >
> > > Mauri Sandberg (2):
> > > bus: mvebu-mbus: add configuration space aperture
> > > dt-bindings: PCI: mvebu: Add orion5x compatible
> > >
> > > Pali Roh?r (5):
> > > ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> > > pcie_setup()
> > > PCI: mvebu: Remove unused busn member
> > > PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> > > PCI: mvebu: Add support for Orion PCIe controller
> > > ARM: dts: orion5x: Add PCIe node
> > >
> > > .../devicetree/bindings/pci/mvebu-pci.txt | 4 +-
> > > arch/arm/boot/dts/orion5x.dtsi | 51 +++++
> > > arch/arm/mach-orion5x/common.c | 13 --
> > > arch/arm/mach-orion5x/pci.c | 14 ++
> > > drivers/bus/mvebu-mbus.c | 26 ++-
> > > drivers/pci/controller/Kconfig | 4 +-
> > > drivers/pci/controller/pci-mvebu.c | 202 ++++++++++++++----
> > > include/linux/mbus.h | 1 +
> > > 8 files changed, 256 insertions(+), 59 deletions(-)
> > >
> > > --
> > > 2.20.1
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > [email protected]
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Friday 11 November 2022 13:49:57 Lorenzo Pieralisi wrote:
> On Mon, Nov 07, 2022 at 12:28:24AM +0100, Pali Rohár wrote:
> > On Thursday 27 October 2022 16:10:48 Lorenzo Pieralisi wrote:
> > > On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> > > > Hello! This patch series add support for Orion PCIe controller into
> > > > pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> > > > to parse all physical addresses from device tree files according to
> > > > mvebu-pci.txt documentation, allow access to all extended PCIe config
> > > > space registers and use modern kernel API pci_remap_cfgspace() and
> > > > mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> > > >
> > > > Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> > > > there because this change and it is de-facto API between dts files and
> > > > kernel used for a long time. Note that it is misused according to PCI
> > > > device tree bindings, but we have to follow this Marvell bindings to do
> > > > not introduce backward incompatibility issues for other non-Orion
> > > > platforms.
> > > >
> > > > Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> > > > PCIe AER is working too (one of the feature which proved that access to
> > > > extended PCIe config registers is working fine).
> > > >
> > > > After this patch is accepted we are planning to look at existing Orion
> > > > arch specific code and covert it to use this new DT based pci-mvebu.c
> > > > code. Later this would allow to kill arch specific Orion PCIe code,
> > > > which is in arch/arm/plat-orion/pcie.c and parts also in file
> > > > arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> > > >
> > > > This patch series depends on another patches:
> > > > https://lore.kernel.org/linux-pci/[email protected]/
> > > > https://lore.kernel.org/linux-pci/[email protected]/
> > >
> > > Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?
> >
> > IIRC above two dependent patches still applies on master branch and this
> > patch series applies on above two dependent patches.
>
> Which I can't merge for reasons you are aware of already.
>
> So, does this series _really_ depend on the two patches above ?
>
> I don't think so but let me ask again.
>
> Lorenzo
Yes, this patch series depends on above tow patches. Kirkwood and older
platforms (including the oldest one Orion) needs fixes for registering
and handling of shared interrupts.
> > > Thanks,
> > > Lorenzo
> > >
> > > > Mauri Sandberg (2):
> > > > bus: mvebu-mbus: add configuration space aperture
> > > > dt-bindings: PCI: mvebu: Add orion5x compatible
> > > >
> > > > Pali Rohár (5):
> > > > ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> > > > pcie_setup()
> > > > PCI: mvebu: Remove unused busn member
> > > > PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> > > > PCI: mvebu: Add support for Orion PCIe controller
> > > > ARM: dts: orion5x: Add PCIe node
> > > >
> > > > .../devicetree/bindings/pci/mvebu-pci.txt | 4 +-
> > > > arch/arm/boot/dts/orion5x.dtsi | 51 +++++
> > > > arch/arm/mach-orion5x/common.c | 13 --
> > > > arch/arm/mach-orion5x/pci.c | 14 ++
> > > > drivers/bus/mvebu-mbus.c | 26 ++-
> > > > drivers/pci/controller/Kconfig | 4 +-
> > > > drivers/pci/controller/pci-mvebu.c | 202 ++++++++++++++----
> > > > include/linux/mbus.h | 1 +
> > > > 8 files changed, 256 insertions(+), 59 deletions(-)
> > > >
> > > > --
> > > > 2.20.1
> > > >
> > > >
> > > > _______________________________________________
> > > > linux-arm-kernel mailing list
> > > > [email protected]
> > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel