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]

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

2017-09-21 15:09 GMT+09:00 Oleksij Rempel <ore@...gutronix.de>:
> 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.



BTW, I am not forcing you to change the SOCFPGA DTS.
It is up to you and Dihn whether change it or not.

I do not have any SOCFPGA board.



-- 
Best Regards
Masahiro Yamada