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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists