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] [day] [month] [year] [list]
Date:   Thu, 26 Jan 2023 18:47:48 +0000
From:   "Hawkins, Nick" <nick.hawkins@....com>
To:     Arnd Bergmann <arnd@...db.de>, "soc@...nel.org" <soc@...nel.org>
CC:     Guenter Roeck <linux@...ck-us.net>,
        "Verdun, Jean-Marie" <verdun@....com>,
        Rob Herring <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        Russell King <linux@...linux.org.uk>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 1/2] ARM: dts: add GXP Support for fans and SPI

> > @@ -52,76 +52,102 @@
> > cache-level = <2>;
> > };
> > 
> > - ahb@...00000 {
> > + ahb@...00000 {
> > compatible = "simple-bus";
> address-cells = <1>;
> > #size-cells = <1>;
> > - ranges = <0x0 0xc0000000 0x30000000>;
> > + ranges = <0x0 0x80000000 0xf000000>,
> > + <0x40000000 0xc0000000 0x40000000>;


> In the changelog text for the first patch that moves the
> ranges down, it would make sense to describe why this specific
> move is done. "to accommodate the SPI and fan driver
> register requirements" does not actually tell me why it was
> first thought that the bus starts at 0xc0000000 but now starts
> at 0x80000000 and has a weird hole.


> Please explain how you determined the location of the hole and
> the 0x80000000 offset. Are these from the datasheet, from
> the hardware design or did you make them up because you thought
> this is what I want?

Greetings Arnd,

These are from a specification; I was mapping all the
registers that were not host related, but we need to
include those now.

The AHB section of registers indeed does start at
0x80000000. The layout of AHB is as follows:

0x80000000 - 0xa0000000 are host registers

Then there is a section of registers we do not currently want to
access as it is reserved which is mapped from:

0xa0000000 - 0xc0000000

Then we have more registers ranging from
0xc0000000 - 0xffff0000 that we will be accessing.

Hence, I believe the proper ranges for this would be:

ranges = <0x0 0x80000000 0x20000000
             0x40000000 0xc0000000 0x3fff0000>;

/* 0x80000000 - 0xa0000000 and 0xc0000000 - 0xffff0000 */

> > dma-ranges;

> Having a 1:1 translation for DMA addresses is actually an indication
> that the MMIO addresses on the bus might also be directly
> mapped, rather than offset: If AHB addresses 0x0-0x80000000
> refer to the local MMIO registers, there is no more room
> for addressing RAM in the same addresses.

I believe that this property should no longer be present here.

DMA is in the area before 0x80000000.

Thanks,

-Nick Hawkins



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ