linux-kernel - Re: [PATCH v3 2/2] asm-generic: Add new pci.h and use it

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]

Message-Id: <41B9AC54-DCFE-4055-B950-265B3CBDD842@jrtc27.com>
Date:   Fri, 22 Jul 2022 22:39:18 +0100
From:   Jessica Clarke <jrtc27@...c27.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Rob Herring <robh@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Maciej W. Rozycki" <macro@...am.me.uk>,
        Stafford Horne <shorne@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Guo Ren <guoren@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Richard Weinberger <richard@....at>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        Johannes Berg <johannes@...solutions.net>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-csky@...r.kernel.org,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        linux-um <linux-um@...ts.infradead.org>,
        PCI <linux-pci@...r.kernel.org>,
        "open list:GENERIC INCLUDE/ASM HEADER FILES" 
        <linux-arch@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] asm-generic: Add new pci.h and use it

On 22 Jul 2022, at 20:55, Arnd Bergmann <arnd@...db.de> wrote:
> 
> On Fri, Jul 22, 2022 at 6:36 PM Rob Herring <robh@...nel.org> wrote:
>> On Fri, Jul 22, 2022 at 9:27 AM Palmer Dabbelt <palmer@...belt.com> wrote:
>> 
>> From fu740:
>>                       ranges = <0x81000000  0x0 0x60080000  0x0
>> 0x60080000 0x0 0x10000>,      /* I/O */
> ...
>> So again, how does one get a 0 address handed out when that's not even
>> a valid region according to DT? Is there some legacy stuff that
>> ignores the bridge windows?
> 
> The PCI-side port number 0x60080000 gets turned into Linux I/O resource 0,
> which I think is what __pci_assign_resource operates on.
> 
> The other question is why the platform would want to configure the
> PCI bus to have a PCI I/O space window of size 0x10000 at the address
> it's mapped into, rather than putting it at address zero. Is this a hardware
> bug, a bootloader bug, or just badly set up in the DT?
> 
> Putting the PCI address of the I/O space window at port 0 is usually
> better because it works with PCI devices and drivers that assume that
> port numbers are below 0xfffff, and makes the PCI port number match
> the Linux port number.

Possibly related is the (harmless) warning spew seen during boot on
FreeBSD. The bridge, and all downstream ones, reset to having I/O
window 0x0-0xfff and memory/prefetch window 0x0-0xfffff (which FreeBSD
tries to allocate, fails because that’s outside the valid ranges above,
so it then just paves over with a sane fresh config). Linux resets the
controller on probe so this is the initial state when enumerating, and
perhaps that’s not handled so gracefully as on FreeBSD (which also
resets in device_attach, the second half of what Linux calls probe)?

Jess