linux-kernel - Re: [PATCH] dt-bindings: nand: denali: reduce the register space in the example

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:   Thu, 21 Sep 2017 08:09:34 +0200
From:   Oleksij Rempel <ore@...gutronix.de>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     linux-mtd@...ts.infradead.org,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
        devicetree@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Brian Norris <computersforpeace@...il.com>,
        Richard Weinberger <richard@....at>,
        David Woodhouse <dwmw2@...radead.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] dt-bindings: nand: denali: reduce the register space in
 the example

Hi,

On 21.09.2017 07:26, Masahiro Yamada wrote:
> Hi.

......
>> Hm.. according to
>> https://www.altera.com/en_US/pdfs/literature/hb/cyclone-v/cyclone5_handbook.pdf
>> Table 13-18: NAND Controller Module Data Space Address Range
>>
>> Module Instance       Start Address        End Address
>> NAND_DATA             0xFF900000           0xFF9FFFFF
>>
>> So <0xff900000 0x100000> seems to be a proper value.
>>
> 
> The Alrera's SOCFPGA document describes so.
> It is up to each SoC vendor how to describe the register space.
> 
> I am focusing on the Denali IP
> because this IP is used among several SoCs.
> 
> 
> 
> You can see the peripheral region map
> starting at page 1-18 of the document you referred to:
> 
> Slave ID      Description                  Base Addr      Size
> ---------------------------------------------------------------
> L3REGS        L3 interconnect GPV          0xFF800000      1 MB
> NANDDATA      NAND flash controller data   0xFF900000     64 KB
> QSPIDATA      Quad SPI flash data          0xFFA00000      1 MB
> 
> (In the doc, the base is described as 0xFFB900000, but this is
> apparently a typo.)
> 
> 
> The rationale of the "End Address 0xFF9FFFFF" of NAND_DATA
> is the fact that the base address of the next peripheral (QSPIDATA) is
> 0xFFA00000.
> 
> 
> 
> 
> One more, if you look at the next page,
> 
> Slave ID      Description                      Base Addr     Size
> ---------------------------------------------------------------
> NANDREGS      NAND flash controller registers   0xFFB80000   64 KB
> FPGAMGRDATA   FPGA manager configuration data   0xFFB90000    4 KB
> 
> 
> The size of NAND register space is described as 64KB,
> but the rationale is just the start of the next peripheral is 0xFFB90000.
> 
> (0xFFB90000 - 0xFFB80000 = 0x10000 = 64KB)
> 
> 
> 
> Altera apparently reserved address space just for the purpose
> of matching the end address to the base address of the next peripheral.
> 
> 
> That means, this document specifies address region
> much bigger than the IP actually provides.
> 
> 
> If you look at page 13-6, there are only two registers
> in NANDDATA space.
> 
> Table 13-4: Register Map for Indexed Addressing
> Control   0x0
> Data      0x10
> 
> 
> 
> For NANDREGS, in page 13-106, the following is the last register
> in the NANDREGS space.
> 
> lun_status_cmd
> Offset 0x7A0
> 
> Obviously, 0x1000 (4KB) is enough for NANDREGS.
> 
> To conclude this, this binding document was written
> based on the Altera's SOCFPGA specification.
> 
> Altera specifies the region size
> so that end address matches to the base of the next peripheral.
> This is just a matter of SOCFPGA address mapping.
> 
> In my opinion, the binding document should not be oriented
> to a particular SoC, which is not true for other SoCs.
ok. Thank you for detailed response.