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
| ||
|
Date: Mon, 14 Feb 2022 17:22:34 +0100 From: Ahmad Fatoum <a.fatoum@...gutronix.de> To: Tokunori Ikegami <ikegami.t@...il.com>, Thorsten Leemhuis <regressions@...mhuis.info>, linux-mtd@...ts.infradead.org, Joakim.Tjernlund@...inera.com, miquel.raynal@...tlin.com, vigneshr@...com, richard@....at, "regressions@...ts.linux.dev" <regressions@...ts.linux.dev> Cc: Chris Packham <chris.packham@...iedtelesis.co.nz>, Brian Norris <computersforpeace@...il.com>, David Woodhouse <dwmw2@...radead.org>, marek.vasut@...il.com, cyrille.pitchen@...ev4u.fr, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Pengutronix Kernel Team <kernel@...gutronix.de>, linuxppc-dev@...ts.ozlabs.org Subject: Re: [BUG] mtd: cfi_cmdset_0002: write regression since v4.17-rc1 Hello Tokunori-san, On 13.02.22 17:47, Tokunori Ikegami wrote: > Hi Ahmad-san, > > Thanks for your confirmations. Sorry for late to reply. No worries. I appreciate you taking the time. > Could you please try the patch attached to disable the chip_good() change as before? > I think this should work for S29GL964N since the chip_ready() is used and works as mentioned. yes, this resolves my issue: Tested-by: Ahmad Fatoum <a.fatoum@...gutronix.de> >>>> Doesn't seem to be a buffered write issue here though as the writes >>>> did work fine before dfeae1073583. Any other ideas? >>> At first I thought the issue is possible to be resolved by using the word write instead of the buffered writes. >>> Now I am thinking to disable the changes dfeae1073583 partially with any condition if possible. >> What seems to work for me is checking if chip_good or chip_ready >> and map_word is equal to 0xFF. I can't justify why this is ok though. >> (Worst case bus is floating at this point of time and Hi-Z is read >> as 0xff on CPU data lines...) > > Sorry I am not sure about this. > I thought the chip_ready() itself is correct as implemented as the data sheet in the past. > But it did not work correctly so changed to use chip_good() instead as it is also correct. What exactly in the datasheet makes you believe chip_good is not appropriate? Cheers, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Powered by blists - more mailing lists