Messages in this thread | | | Date | Wed, 2 Mar 2022 14:25:22 +0100 | From | Marek Behún <> | Subject | Re: [PATCH] arm64: dts: marvell: armada-37xx: Remap IO space to bus address 0x0 |
| |
On Wed, 2 Mar 2022 14:15:15 +0100 Marek Behún <kabel@kernel.org> wrote:
> On Wed, 2 Mar 2022 14:06:01 +0100 > Andrew Lunn <andrew@lunn.ch> wrote: > > > On Tue, Mar 01, 2022 at 10:25:39AM +0100, Pali Rohár wrote: > > > On Monday 28 February 2022 17:42:03 Gregory CLEMENT wrote: > > > > > Hello Pali, > > > > > > > > > >> Remap PCI I/O space to the bus address 0x0 in the Armada 37xx > > > > >> device-tree in order to support legacy I/O port based cards which have > > > > >> hardcoded I/O ports in low address space. > > > > >> > > > > >> Some legacy PCI I/O based cards do not support 32-bit I/O addressing. > > > > >> > > > > >> Since commit 64f160e19e92 ("PCI: aardvark: Configure PCIe resources from > > > > >> 'ranges' DT property") this driver can work with I/O windows which > > > > >> have > > > > > > > > > > Should we add a "Fixes: 64f160e19e92 ("PCI: aardvark: Configure PCIe > > > > > resources from 'ranges' DT property")" tag ? > > > > > > > > Waiting for your confirmation I tried to applied it but it failed. > > > > > > > > Did you base this patch on v5.17-rc1 ? > > > > > > > > Gregory > > > > > > Hello! This change is breaking booting of Turris Mox kernel with older > > > bootloader due to bugs in bootloader. > > > > Do you know what actually goes wrong? > > > > I've not been involved in the discussion, but looking at the comments > > above, not changing the space can result in non-working cards. So it > > does sound like something which in general we want to do. Does the > > current code assume the bootloader has initialized some registers with > > specific values? Can that be moved into the driver so it also works > > with older bootloaders? > > No. TF-A may remap CPU PCIe window, and so U-Boot fixes these addresses > in device-tree. But the fixup function was at first written in such a > way that it assumes that the ranges propreties contains specific > values. The proposed DT change, together with the fixup function in > older U-Boot, will break ranges property to non-functional state. > > See corresponding U-Boot patches > > https://patchwork.ozlabs.org/project/uboot/patch/20200408172522.18941-5-marek.behun@nic.cz/ > https://patchwork.ozlabs.org/project/uboot/patch/20210526155940.26141-5-pali@kernel.org/ > https://patchwork.ozlabs.org/project/uboot/patch/20220223125232.7974-1-kabel@kernel.org/ > > The last patch is not merged yet.
To explain more: - the first patch added the ranges property fixup. After that patch (which was applied sometime not long after 8th April 2020) U-Boot fixes the ranges property in a way that does not work with the proposed DT change. - the second patch extended the fixup, but it still won't work correctly with the proposed DT change - the third U-Boot patch will fix this issue, afterwards the DT change won't break PCIe. This patch is not yet merged in U-Boot
It is questionable how many users have updated U-Boot to the version with first fixup. AFAIK we at Turris did not make an automatic update for U-Boot yet for Turris MOX, it was done manually only for some boards that had some problems or users wanted certain features.
But we can't change the device-tree because it will break the functinality for some users.
What we could do is add another patch to U-Boot that would change IO window address if certain conditions are met (for example if the ranges proprety was not changed by the user and thus contains a specific value that can be checked for).
Marek
| |