linux-kernel - Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 20 Jul 2022 19:53:15 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Mauri Sandberg <maukka@....kapsi.fi>,
        linux-pci <linux-pci@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andrew Lunn <andrew@...n.ch>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Gregory CLEMENT <gregory.clement@...tlin.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

On Wednesday 20 July 2022 11:40:40 Rob Herring wrote:
> On Wed, Jul 20, 2022 at 10:13 AM Pali Rohár <pali@...nel.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@...nel.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/