linux-kernel - Re: [PATCH v2 0/2] mtd: nand: wait for tWHR, and fix the setup_data

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 Oct 2017 02:04:28 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Marc Gonzalez <marc_gonzalez@...madesigns.com>
Cc:     Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Mason <slash.tmp@...e.fr>, Richard Weinberger <richard@....at>,
        LKML <linux-kernel@...r.kernel.org>,
        Marek Vasut <marek.vasut@...il.com>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
        Brian Norris <computersforpeace@...il.com>,
        David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH v2 0/2] mtd: nand: wait for tWHR, and fix the
 setup_data_interface of Denali

Hi Marc,

2017-10-19 23:58 GMT+09:00 Marc Gonzalez <marc_gonzalez@...madesigns.com>:
> On 13/10/2017 10:34, Masahiro Yamada wrote:
>
>> 2017-10-04 20:05, Marc Gonzalez wrote:
>>
>>> On 29/09/2017 16:33, Masahiro Yamada wrote:
>>>
>>>> tango_nand.c is the only driver that sets NAND_WAIT_TCCS.
>>>>
>>>> Now, there is completely no delay when reading out the ID.
>>>>
>>>>
>>>> One safe change might be apply this patch,
>>>> then set NAND_WAIT_TWHR to tango_nand.c
>>>>
>>>>
>>>> I am guessing NAND_WAIT_TCCS was added for it.
>>>> Theoretically, I do not see logical difference between tCCS and tWHR.
>>>>
>>>> I am CCing Marc Gonzalez, the author of tango_nand.c
>>>
>>> Hello Masahiro,
>>>
>>> I remember having issues reading the ONFI ID when I was writing
>>> the driver, a year ago. Sometimes, the first few bytes appeared
>>> to be missing. This looked like a timing issue.
>>>
>>> Adding the dev_ready call-back solved the problem. Do you think
>>> that was by accident?
>>
>> It is odd to use dev_ready() hook to insert delay for the READ ID command.
>> READ ID command never toggles the device's Ready/Busy# pin.
>>
>>
>>> When I have more time, I will test the 4.14
>>> branch, to see if there are any issues with the current driver.
>>
>>
>> Yeah, I highly recommend you to test your driver on the latest kernel.
>> I suspect it is broken because READ ID command in the generic hook
>> has absolutely zero delay.
>>
>> As I proposed already, the correct fix it to wait for tWHR.
>
> Hello Masahiro,
>
> I checked out v4.14-rc5, imported the DMA driver (which is, unfortunately,
> not upstream) and DT nodes.


Thanks for your test report.

I was worried since you said
you had issues reading the ONFI ID.

Anyway, it is OK if your driver is working.

Thanks.




-- 
Best Regards
Masahiro Yamada