linux-kernel - Re: [PATCH v4 3/5] ARM: dts: add GXP Support for fans and SPI

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: <6bae68eb-866f-4b78-b4db-e3154feec28e@app.fastmail.com>
Date:   Thu, 12 Jan 2023 17:00:52 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Hawkins, Nick" <nick.hawkins@....com>
Cc:     "Verdun, Jean-Marie" <verdun@....com>,
        "Jean Delvare" <jdelvare@...e.com>,
        "Guenter Roeck" <linux@...ck-us.net>,
        "Rob Herring" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "Jonathan Corbet" <corbet@....net>,
        "Russell King" <linux@...linux.org.uk>,
        "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 3/5] ARM: dts: add GXP Support for fans and SPI

On Thu, Jan 12, 2023, at 16:40, Hawkins, Nick wrote:
>> > - ahb@...00000 {
>> > + ahb@...00000 {
>> > compatible = "simple-bus";
>> > #address-cells = <1>;
>> > #size-cells = <1>;
>> > - ranges = <0x0 0xc0000000 0x30000000>;
>> > + ranges = <0x0 0x80000000 0xf000000>, /* 0x80000000 - 0x8f000000 */
>> > + <0x40000000 0xc0000000 0x7fffffff>; /* 0xc0000000 - 0xffffffff */
>
>
>> I'm a bit confused by the change in the mappings: are you
>> sure this all the same ahb bus and not two separate buses?
>
> Yes this is the same bus, however we are not including all of
> it as it maps some host registers that we do not want to access
> at this time. 

If the two ranges are actually translated separately on the
bus, you could also decide to enumerate the translations with
a 64-bit local address and make the upper word an enumeration,
such as

ranges = <0x1 0x0 0x80000000 0xf000000>,
         <0x2 0x0 0xc0000000 0x30000000>;

then you get small numbers again in the 'reg' properties
that are easier to read and ideally match the bus-local
numbers from the hardware manual.

>> The comment for the second range looks wrong to me, as
>> you define a 2GB (minus one byte) sized mapping but the
>> comment only lists a 1GB (including the last byte) mapping.
>
>
>> I would expect that the original 0x30000000 (including the
>> last byte) was correct here.
>
> Yes this was incorrect, I believe it should be:
>
> ranges = <0x0 0x80000000 0xf000000>, /* 0x80000000 - 0x8f000000 */
>                 <0x40000000 0xc0000000 0x3fffffff>; /* 0xc0000000 - 
> 0xffffffff */
>
> I will create a v5 version of this patchset with just this and the
> defconfig for your review.

Now it almost matches, except for the final byte, as the
range actually ends at 0xfffffffe not 0xffffffff if you make
the size one byte less than 1GB.

Is there a special register in the last byte?

>> > - vic1: interrupt-controller@...00000 {
>> > + vic1: interrupt-controller@...000 { /* 0x80f00000 */
>
>
>> This is not the same address as before. I'm also not sure the
>> comment is helpful here.
>
> My understanding was that the physical address would be the
> 0x80000000 from the first range plus the 0xf00000 to be
> 0x80f00000?

I suppose the physical address in the old mapping was actually
outside of the 0xc0000000-0xefffffff range, so it wasn't
even accessible. If the addresses are interpreted to wrap around
at the end of the mapping, that would have made the CPU visible
address 0xe0f00000 (0xc0000000 + (0x80f00000 % 0x30000000)).
If it just wrapped around as a 32-bit number, it would be
0x40f00000 ((0xc0000000 + 0x80f00000)% 0x100000000), but I
don't see you you'd get to 80f00000.

      Arnd