| Message ID | 20220718202843.6766-1-maukka@ext.kapsi.fi |
|---|---|
| Headers | show |
| Series | PCI: mvebu: add support for orion soc | expand |
On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <maukka@ext.kapsi.fi> 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 > 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 <maukka@ext.kapsi.fi> > Cc: Pali Rohár <pali@kernel.org> Nice job, glad you managed to figure this out! > 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, If the idea is to have the PCI_MVEBU driver only used for the DT based orion5x machines, but not the legacy board files, I suspect this breaks the legacy pci driver, unless you move the mbus configuration into the pcie_setup() function. > +/* Relevant only for Orion-1/Orion-NAS */ > +#define ORION5X_PCIE_WA_PHYS_BASE 0xf0000000 > +#define ORION5X_PCIE_WA_VIRT_BASE IOMEM(0xfd000000) You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE should already be part of the DT binding. There is little practical difference here, but I see no value in taking the shortcut here either. For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the definition in arch/arm/mach-orion5x/common.c, and this is rather fragile. Instead, please use ioremap() to create a mapping at runtime. The ioremap() implementation on ARM is smart enough to reuse the address from the static mapping in common.c, but will also keep working if that should go away. > +#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); > +} > + This is probably good enough here, though I think you could also use the trick from drivers/pci/ecam.c and map each bus at a time. Arnd
Hello! On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote: > On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <maukka@ext.kapsi.fi> 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 > > 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 <maukka@ext.kapsi.fi> > > Cc: Pali Rohár <pali@kernel.org> > > Nice job, glad you managed to figure this out! > > > 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, > > If the idea is to have the PCI_MVEBU driver only used for the DT based orion5x > machines, but not the legacy board files, I suspect this breaks the legacy > pci driver, unless you move the mbus configuration into the pcie_setup() > function. > > > +/* Relevant only for Orion-1/Orion-NAS */ > > +#define ORION5X_PCIE_WA_PHYS_BASE 0xf0000000 > > +#define ORION5X_PCIE_WA_VIRT_BASE IOMEM(0xfd000000) > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE > should already be part of the DT binding. Of course! But the issue is that we do not know how to do this DT binding. I have already wrote email with asking for help in which property and which format should be this config range defined, but no answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/ > There is little practical difference > here, but I see no value in taking the shortcut here either. > > For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the > definition in arch/arm/mach-orion5x/common.c, and this is rather fragile. > > Instead, please use ioremap() to create a mapping at runtime. The ioremap() > implementation on ARM is smart enough to reuse the address from the static > mapping in common.c, but will also keep working if that should go away. I'm planning to work with Mauri on this, but current blocker is DT. > > +#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); > > +} > > + > > This is probably good enough here, though I think you could also use > the trick from drivers/pci/ecam.c and map each bus at a time. > > Arnd Yes, there are also helper functions like map bus and etc. which could simplify this code. I'm planning to do cleanups once we have fully working driver for Orion.
On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote: > On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote: > > > +/* Relevant only for Orion-1/Orion-NAS */ > > > +#define ORION5X_PCIE_WA_PHYS_BASE 0xf0000000 > > > +#define ORION5X_PCIE_WA_VIRT_BASE IOMEM(0xfd000000) > > > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE > > should already be part of the DT binding. > > Of course! But the issue is that we do not know how to do this DT > binding. I have already wrote email with asking for help in which > property and which format should be this config range defined, but no > answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/ Ah, I had not seen that email. Quoting from there: > So my question is: How to properly define config space range in device > tree file? In which device tree property and in which format? Please > note that this memory range of config space is PCIe root port specific > and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe > IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi This is probably a question for Rob as the mvebu driver is a rather special case. Normally this would just be a 'reg' property of the host bridge, but I think in your case the root device is imaginary, and the ports under it are the actual hardware devices, so you'll probably have to do the same thing as the armada-385, translating the mbus ranges for the config space in the "ranges" property of the parent, and then referring to them by PCI MMIO addresses using the assigned-addresses property to pass the config-space registers as a second set of registers in addition to the first set. > > There is little practical difference > > here, but I see no value in taking the shortcut here either. > > > > For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the > > definition in arch/arm/mach-orion5x/common.c, and this is rather fragile. > > > > Instead, please use ioremap() to create a mapping at runtime. The ioremap() > > implementation on ARM is smart enough to reuse the address from the static > > mapping in common.c, but will also keep working if that should go away. > > I'm planning to work with Mauri on this, but current blocker is DT. Ok. It should not be hard to do this first, as you just need to pass the same physical address that you pass in the mbus setup, but I agree it's easier to do this afterwards to avoid having to rewrite it again. > > This is probably good enough here, though I think you could also use > > the trick from drivers/pci/ecam.c and map each bus at a time. > > > Yes, there are also helper functions like map bus and etc. which could > simplify this code. I'm planning to do cleanups once we have fully > working driver for Orion. Ok. This is probably not worth the effort if the old driver doesn't already do provide access to the high registers. Arnd
On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <maukka@ext.kapsi.fi> 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 Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote: > On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote: > > On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote: > > > > +/* Relevant only for Orion-1/Orion-NAS */ > > > > +#define ORION5X_PCIE_WA_PHYS_BASE 0xf0000000 > > > > +#define ORION5X_PCIE_WA_VIRT_BASE IOMEM(0xfd000000) > > > > > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE > > > should already be part of the DT binding. > > > > Of course! But the issue is that we do not know how to do this DT > > binding. I have already wrote email with asking for help in which > > property and which format should be this config range defined, but no > > answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/ > > Ah, I had not seen that email. Quoting from there: > > > So my question is: How to properly define config space range in device > > tree file? In which device tree property and in which format? Please > > note that this memory range of config space is PCIe root port specific > > and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe > > IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi > > This is probably a question for Rob as the mvebu driver is a rather special > case. Normally this would just be a 'reg' property of the host bridge, > but I think > in your case the root device is imaginary, and the ports under it are the > actual hardware devices yes > so you'll probably have to do the same thing as > the armada-385, translating the mbus ranges for the config space in the > "ranges" property of the parent Problem is that "ranges" in PCIe are used for specifying MEM and IO mappings and kernel PCI code does not allow any other type. > and then referring to them by PCI > MMIO addresses using the assigned-addresses property to pass the > config-space registers as a second set of registers in addition to the > first set. It is more complicated. PCIe MEM and IO memory ranges are defined in "soc" node in "pcie-mem-aperture" and "pcie-io-aperture" properties. These ranges are shared across all PCIe controllers and assigning slices of these ranges to specific devices is done later by dynamic allocation. "soc" node is bind to mbus driver (which parse these properties) and provides API for other kernel drivers for dynamic allocation of memory from pcie aperture. In pcie node is just indirect reference to PCIe MEM and IO via MBUS_ID() macro and it is pci-mvebu.c driver who ask mbus driver for PCIe MEM and IO dynamic allocation. So because PCIe config space is not of type PCIe MEM nor PCIe IO (obviously) it cannot use "ranges" property. Because DT pcie nodes use "reg" property for specifying BDF address, we cannot use neither "reg" property for specifying memory range of PCIe config space. And here I'm lost. My guess is that proper way is to define "pcie-cfg-aperture" in "soc" node where would be defined physical address range without any binding to controller, then extend mbus driver to export API also for PCIe CFG and add code which dynamically assign slice of this range to some controller. And then use this new API by pci-mvebu.c to access config space. But pci-mvebu.c needs to know MBUS_ID() attributes which needs to be defined somewhere in pcie DT node... > > > There is little practical difference > > > here, but I see no value in taking the shortcut here either. > > > > > > For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the > > > definition in arch/arm/mach-orion5x/common.c, and this is rather fragile. > > > > > > Instead, please use ioremap() to create a mapping at runtime. The ioremap() > > > implementation on ARM is smart enough to reuse the address from the static > > > mapping in common.c, but will also keep working if that should go away. > > > > I'm planning to work with Mauri on this, but current blocker is DT. > > Ok. It should not be hard to do this first, as you just need to pass the > same physical address that you pass in the mbus setup, but I agree > it's easier to do this afterwards to avoid having to rewrite it again. > > > > This is probably good enough here, though I think you could also use > > > the trick from drivers/pci/ecam.c and map each bus at a time. > > > > > Yes, there are also helper functions like map bus and etc. which could > > simplify this code. I'm planning to do cleanups once we have fully > > working driver for Orion. > > Ok. This is probably not worth the effort if the old driver doesn't already > do provide access to the high registers. > > Arnd If we have free 256MB in physical address space, then we can implement it easily. It is just changing _size_ argument. I'm not sure how much DDR RAM has Orion, but if only 2GB then we should be fine (remaining 2GB should be enough for all peripherals + 256MB for PCIe config space). Main issue is that there is no Orion documentation which would describe how direct mapping of PCIe config space is working. (see also https://lore.kernel.org/linux-doc/20220719080807.16729-1-pali@kernel.org/) So we can only set "size" of the physical config space mapping and if we choose smaller size then we cannot access upper registers. I do not see any option how to specify "offset" for physical config space to allow mapping just one PCI bus. What we have under full control is virtual address space mapping, so we can just map only one PCI bus to virtual address space from large 256MB physical config address space.
> If we have free 256MB in physical address space, then we can implement > it easily. It is just changing _size_ argument. I'm not sure how much > DDR RAM has Orion, but if only 2GB then we should be fine (remaining 2GB > should be enough for all peripherals + 256MB for PCIe config space). All the Orion5x devices i've seen have had small amounts of RAM, 64MB, maybe 128M. It seems very unlikely there are any with 2GB for RAM. So i don't see a problem with taking 256MB of physical addresses for PCI. Andrew
On Wed, Jul 20, 2022 at 6:13 PM Pali Rohár <pali@kernel.org> wrote: > > On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote: > > On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote: > > so you'll probably have to do the same thing as > > the armada-385, translating the mbus ranges for the config space in the > > "ranges" property of the parent > > Problem is that "ranges" in PCIe are used for specifying MEM and IO > mappings and kernel PCI code does not allow any other type. > > > and then referring to them by PCI > > MMIO addresses using the assigned-addresses property to pass the > > config-space registers as a second set of registers in addition to the > > first set. > > It is more complicated. PCIe MEM and IO memory ranges are defined in > "soc" node in "pcie-mem-aperture" and "pcie-io-aperture" properties. > These ranges are shared across all PCIe controllers and assigning slices > of these ranges to specific devices is done later by dynamic allocation. > "soc" node is bind to mbus driver (which parse these properties) and > provides API for other kernel drivers for dynamic allocation of memory > from pcie aperture. In pcie node is just indirect reference to PCIe MEM > and IO via MBUS_ID() macro and it is pci-mvebu.c driver who ask mbus > driver for PCIe MEM and IO dynamic allocation. > > So because PCIe config space is not of type PCIe MEM nor PCIe IO > (obviously) it cannot use "ranges" property. Because DT pcie nodes use > "reg" property for specifying BDF address, we cannot use neither "reg" > property for specifying memory range of PCIe config space. > > And here I'm lost. > > My guess is that proper way is to define "pcie-cfg-aperture" in "soc" > node where would be defined physical address range without any binding > to controller, then extend mbus driver to export API also for PCIe CFG > and add code which dynamically assign slice of this range to some > controller. And then use this new API by pci-mvebu.c to access config > space. But pci-mvebu.c needs to know MBUS_ID() attributes which needs to > be defined somewhere in pcie DT node... I think you can define a "ranges" property in the parent node that converts the MBUS address into a fake PCI MEM space address, and this is what the Armada 385 example does with <0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000> In the child you can refer to this using the "assigned-addresses" property and then use the "ranges" to ensure that only the actual IO and MEM space addresses are translated. The alternative would be to do away with the indirection and make the orion5x variant be more like a single hostbridge, and getting rid of the fake parent. This is closer to what orion5x does at the moment with the old driver, but might be harder to integrate into the new one. > > > > There is little practical difference > > > > here, but I see no value in taking the shortcut here either. > > > > > > > > For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the > > > > definition in arch/arm/mach-orion5x/common.c, and this is rather fragile. > > > > > > > > Instead, please use ioremap() to create a mapping at runtime. The ioremap() > > > > implementation on ARM is smart enough to reuse the address from the static > > > > mapping in common.c, but will also keep working if that should go away. > > > > > > I'm planning to work with Mauri on this, but current blocker is DT. > > > > Ok. It should not be hard to do this first, as you just need to pass the > > same physical address that you pass in the mbus setup, but I agree > > it's easier to do this afterwards to avoid having to rewrite it again. > > > > > > This is probably good enough here, though I think you could also use > > > > the trick from drivers/pci/ecam.c and map each bus at a time. > > > > > > > Yes, there are also helper functions like map bus and etc. which could > > > simplify this code. I'm planning to do cleanups once we have fully > > > working driver for Orion. > > > > Ok. This is probably not worth the effort if the old driver doesn't already > > do provide access to the high registers. > > > > Arnd > > If we have free 256MB in physical address space, then we can implement > it easily. It is just changing _size_ argument. I'm not sure how much > DDR RAM has Orion, but if only 2GB then we should be fine (remaining 2GB > should be enough for all peripherals + 256MB for PCIe config space). I recently checked the sizes as I was researching which boards are actually still usable, and I can confirm what Andrew also said. The only one with 256MB is TS409, everything else has 32MB to 128MB. As I said before, I also see no problem with leaving the smaller mapping, as we know that nobody has ever used the extended config space on orion5x with mainline kernels, and we are not trying to support new hardware. > So we can only set "size" of the physical config space mapping and if we > choose smaller size then we cannot access upper registers. I do not see > any option how to specify "offset" for physical config space to allow > mapping just one PCI bus. > > What we have under full control is virtual address space mapping, so we > can just map only one PCI bus to virtual address space from large 256MB > physical config address space. Right. Arnd
On Wed, Jul 20, 2022 at 10:13 AM Pali Rohár <pali@kernel.org> wrote: > > On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote: > > On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote: > > > On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote: > > > > > +/* Relevant only for Orion-1/Orion-NAS */ > > > > > +#define ORION5X_PCIE_WA_PHYS_BASE 0xf0000000 > > > > > +#define ORION5X_PCIE_WA_VIRT_BASE IOMEM(0xfd000000) > > > > > > > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE > > > > should already be part of the DT binding. > > > > > > Of course! But the issue is that we do not know how to do this DT > > > binding. I have already wrote email with asking for help in which > > > property and which format should be this config range defined, but no > > > answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/ > > > > Ah, I had not seen that email. Quoting from there: > > > > > So my question is: How to properly define config space range in device > > > tree file? In which device tree property and in which format? Please > > > note that this memory range of config space is PCIe root port specific > > > and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe > > > IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi > > > > This is probably a question for Rob as the mvebu driver is a rather special > > case. Normally this would just be a 'reg' property of the host bridge, > > but I think > > in your case the root device is imaginary, and the ports under it are the > > actual hardware devices > > yes > > > so you'll probably have to do the same thing as > > the armada-385, translating the mbus ranges for the config space in the > > "ranges" property of the parent > > Problem is that "ranges" in PCIe are used for specifying MEM and IO > mappings and kernel PCI code does not allow any other type. The kernel does not, but the binding does (well, the original OF PCI bus supplement does, but the schema currently does not). If there's a real need to support config space in ranges, then we can relax the constraints. Rob
On Wednesday 20 July 2022 11:40:40 Rob Herring wrote: > On Wed, Jul 20, 2022 at 10:13 AM Pali Rohár <pali@kernel.org> wrote: > > > > On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote: > > > On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote: > > > > On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote: > > > > > > +/* Relevant only for Orion-1/Orion-NAS */ > > > > > > +#define ORION5X_PCIE_WA_PHYS_BASE 0xf0000000 > > > > > > +#define ORION5X_PCIE_WA_VIRT_BASE IOMEM(0xfd000000) > > > > > > > > > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE > > > > > should already be part of the DT binding. > > > > > > > > Of course! But the issue is that we do not know how to do this DT > > > > binding. I have already wrote email with asking for help in which > > > > property and which format should be this config range defined, but no > > > > answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/ > > > > > > Ah, I had not seen that email. Quoting from there: > > > > > > > So my question is: How to properly define config space range in device > > > > tree file? In which device tree property and in which format? Please > > > > note that this memory range of config space is PCIe root port specific > > > > and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe > > > > IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi > > > > > > This is probably a question for Rob as the mvebu driver is a rather special > > > case. Normally this would just be a 'reg' property of the host bridge, > > > but I think > > > in your case the root device is imaginary, and the ports under it are the > > > actual hardware devices > > > > yes > > > > > so you'll probably have to do the same thing as > > > the armada-385, translating the mbus ranges for the config space in the > > > "ranges" property of the parent > > > > Problem is that "ranges" in PCIe are used for specifying MEM and IO > > mappings and kernel PCI code does not allow any other type. > > The kernel does not, but the binding does (well, the original OF PCI > bus supplement does, but the schema currently does not). If there's a > real need to support config space in ranges, then we can relax the > constraints. > > Rob Personally, I do not care where definition of address range for config space would be defined. Just I need to know where to put it and in which format, so it would be fine for schema checkers, kernel pci core, etc... https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/
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! 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/20220524122817.7199-1-pali@kernel.org/
https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/
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(-)
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/20220524122817.7199-1-pali@kernel.org/ > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/ 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 > linux-arm-kernel@lists.infradead.org > 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/20220524122817.7199-1-pali@kernel.org/ > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/ 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 > linux-arm-kernel@lists.infradead.org > 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/20220524122817.7199-1-pali@kernel.org/ > > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/ > > 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 > > linux-arm-kernel@lists.infradead.org > > 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/20220524122817.7199-1-pali@kernel.org/ > > > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/ > > > > 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 > > > linux-arm-kernel@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > 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/20220524122817.7199-1-pali@kernel.org/ > > > > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/ > > > > > > 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 > > > > linux-arm-kernel@lists.infradead.org > > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel