linux-kernel - Re: [PATCH 2/2] dt-bindings: nand: Add Cadence NAND controller driver

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: <20190205170812.GA18748@global.cadence.com>
Date:   Tue, 5 Feb 2019 17:08:14 +0000
From:   Piotr Sroka <piotrs@...ence.com>
To:     Boris Brezillon <bbrezillon@...nel.org>
CC:     <linux-kernel@...r.kernel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        BrianNorris <computersforpeace@...il.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Richard Weinberger <richard@....at>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        <linux-mtd@...ts.infradead.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH 2/2] dt-bindings: nand: Add Cadence NAND controller driver

The 01/29/2019 18:21, Boris Brezillon wrote:
  
>> +Optional properties:
>> +Driver calculates controller timings base on NAND flash memory timings and
>> +the following delays in picoseconds.
>> +  - cdns,if-skew : Skew value of the output signals of the NAND Flash interface
>> +  - cdns,nand2-delay : Delay value of one NAND2 gate from which
>> +    the delay element is build
>> +  - cdns,board-delay : Estimated Board delay. The value includes the total
>> +    round trip delay for the signals and is used for deciding on values
>> +    associated with data read capture. The example formula for SDR mode is
>> +    the following:
>> +    board_delay = RE#PAD_delay + PCB trace to device + PCB trace from device
>> +    + DQ PAD delay
>
>The unit of those props is not defined, and if possible I'd like to
>avoid specifying custom timing adjustment values in the DT. Looks like
>some of these values are SoC specific (depends on the integration of
>this IP in a SoC) and others are board specific. For SoC specific
>values, this should be attached to the SoC specific compatible at the
>driver level. For board-specific values, I'd prefer to have a generic
>way to describe boards constraints.
Moving SoC specific delays from DTS to the driver data is clear for me. I do not know how to handle a board delay. Could you give me an example how it may be implemented? Where this board related stuff could be placed?

-- 
--
Regards
Piotr Sroka