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 11:40:40 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Pali Rohár <pali@...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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ