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  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:   Sun, 10 May 2020 22:06:35 +0200
From:   Miquel Raynal <>
To:     Masahiro Yamada <>,
Cc:     Miquel Raynal <>,
        Marek Vasut <>,
        Vignesh Raghavendra <>,
        Richard Weinberger <>,
Subject: Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data

On Tue, 2020-03-17 at 07:18:21 UTC, Masahiro Yamada wrote:
> The Denali IP have several registers to specify how many clock cycles
> should be waited between falling/rising signals. You can improve the
> NAND access performance by programming these registers with optimized
> values.
> Because struct nand_sdr_timings represents the device requirement
> in pico seconds, denali_setup_data_interface() computes the register
> values by dividing the device timings with the clock period.
> Marek Vasut reported this driver in the latest kernel does not work
> on his SOCFPGA board. (The on-board NAND chip is mode 5)
> The suspicious parameter is acc_clks, so this commit relaxes it.
> The Denali NAND Flash Memory Controller User's Guide describes this
> register as follows:
>   acc_clks
>     signifies the number of bus interface clk_x clock cycles,
>     controller should wait from read enable going low to sending
>     out a strobe of clk_x for capturing of incoming data.
> Currently, acc_clks is calculated only based on tREA, the delay on the
> chip side. This does not include additional delays that come from the
> data path on the PCB and in the SoC, load capacity of the pins, etc.
> This relatively becomes a big factor on faster timing modes like mode 5.
> Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
> the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
> the timing mode 5.
> We would not go back to the hard-coded acc_clks, but we need to include
> this factor into the delay somehow. Let's say the amount of the additional
> delay is 10000 pico sec.
> In the new calculation, acc_clks is determined by timings->tREA_max +
> data_setup_on_host.
> Also, prolong the RE# low period to make sure the data hold is met.
> Finally, re-center the data latch timing for extra safety.
> [1]
> [2]
> Reported-by: Marek Vasut <>
> Signed-off-by: Masahiro Yamada <>
> Tested-by: Marek Vasut <>

Applied to nand/next, thanks.


Powered by blists - more mailing lists