From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B3A54C433EF for ; Mon, 14 Feb 2022 16:23:49 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Jy8fq3k0Cz3cRC for ; Tue, 15 Feb 2022 03:23:47 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=pengutronix.de (client-ip=2001:67c:670:201:290:27ff:fe1d:cc33; helo=metis.ext.pengutronix.de; envelope-from=a.fatoum@pengutronix.de; receiver=) Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Jy8fL0X4Wz3bYq for ; Tue, 15 Feb 2022 03:23:20 +1100 (AEDT) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[127.0.0.1]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1nJe7f-0008Lp-1r; Mon, 14 Feb 2022 17:22:43 +0100 Message-ID: <579eab10-594c-d6b2-0ddb-ea6ab8e02856@pengutronix.de> Date: Mon, 14 Feb 2022 17:22:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [BUG] mtd: cfi_cmdset_0002: write regression since v4.17-rc1 Content-Language: en-US To: Tokunori Ikegami , Thorsten Leemhuis , linux-mtd@lists.infradead.org, Joakim.Tjernlund@infinera.com, miquel.raynal@bootlin.com, vigneshr@ti.com, richard@nod.at, "regressions@lists.linux.dev" References: <3dbbcee5-81fc-cdf5-9f8b-b6ccb95beddc@pengutronix.de> <0f2cfcac-83ca-51a9-f92c-ff6495dca1d7@gmail.com> <66ee55d9-4f20-6722-6097-e53c2108ea07@gmail.com> From: Ahmad Fatoum In-Reply-To: <66ee55d9-4f20-6722-6097-e53c2108ea07@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linuxppc-dev@lists.ozlabs.org X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linuxppc-dev@lists.ozlabs.org, "linux-kernel@vger.kernel.org" , marek.vasut@gmail.com, Chris Packham , Pengutronix Kernel Team , cyrille.pitchen@wedev4u.fr, Brian Norris , David Woodhouse Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 >>>> 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 |