From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [85.220.165.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 47905437E for ; Tue, 8 Mar 2022 09:44:40 +0000 (UTC) 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 1nRWOF-0004l1-EX; Tue, 08 Mar 2022 10:44:23 +0100 Message-ID: Date: Tue, 8 Mar 2022 10:44:14 +0100 Precedence: bulk X-Mailing-List: regressions@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 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" Cc: Chris Packham , Brian Norris , David Woodhouse , marek.vasut@gmail.com, cyrille.pitchen@wedev4u.fr, "linux-kernel@vger.kernel.org" , Pengutronix Kernel Team , linuxppc-dev@lists.ozlabs.org References: <3dbbcee5-81fc-cdf5-9f8b-b6ccb95beddc@pengutronix.de> <0f2cfcac-83ca-51a9-f92c-ff6495dca1d7@gmail.com> <66ee55d9-4f20-6722-6097-e53c2108ea07@gmail.com> <579eab10-594c-d6b2-0ddb-ea6ab8e02856@pengutronix.de> <117facba-ba33-349d-1085-25315cc1ae92@gmail.com> <9621c512-06f2-17b2-5c68-943b1f0981eb@gmail.com> From: Ahmad Fatoum In-Reply-To: <9621c512-06f2-17b2-5c68-943b1f0981eb@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: regressions@lists.linux.dev Hello Tokunori, On 06.03.22 16:49, Tokunori Ikegami wrote: > Hi, > > On 2022/03/04 20:11, Ahmad Fatoum wrote: >> Hello Tokunori-san, >> >> On 20.02.22 13:22, Tokunori Ikegami wrote: >>> Hi Ahmad-san, >>> >>> Could you please try the version 2 patch attached for the error case? >>> This version is to check the DQ true data 0xFF by chip_good(). >> I had a similar patch locally as well at first. I just tested yours >> and I can't reproduce the issue. > Thanks for your support. > Sorry if possible could you please retest the attached the patch again since this fixed the version 1 patch maintainer review comments? Works good. Tested-by: Ahmad Fatoum >>> But I am not sure if this works or not since the error is possible to be caused by Hi-Z 0xff on floating bus or etc. >> That it works for me could be because of Hi-Z 0xff, which is why >> decided against it. > I see. >> >>>>>>> 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? >>>> I just mentioned about the actual issue behaviors as not worked chip_good() on S29GL964N and not worked chip_ready() on MX29GL512FHT2I-11G before etc. >>>> Anyway let me recheck the data sheet details as just checked it again quickly but needed more investigation to understand. >>> As far as I checked still both chip_good() and chip_ready() seem correct but still the root cause is unknown. >>> If as you mentioned the issue was cased by the DQ true data 0xFF I am not sure why the read work without any error after the write operation. >>> Also if the error was caused by the Hi-Z 0xff on floating bus as mentioned I am not sure why the read work without any error after the write operation with chip_ready(). >>> Sorry anyway the root cause is also unknown when the write operation was changed to use chip_good() instead of chip_ready(). >> I've be ok with v1 then. Restores working behavior for me and shouldn't break others. > > Noted but still I am thinking the version 2 patch to check 0xff seems better than to use chip_ready() so let me consider this again later. The original version has less room for surprise as it restores previously working behavior. Assuming 0xFF to be good without backing from documentation is more risky IMO. Thanks for your continued support, Ahmad > > Regards, > Ikegami > >> >> Cheers and thanks again, >> Ahmad >> >>> Regards, >>> Ikegami >>> >>>> Regards, >>>> Ikegami >>>> >>>>> 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 | 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 C5322C433F5 for ; Tue, 8 Mar 2022 09:45:27 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KCVn11qYrz3bmf for ; Tue, 8 Mar 2022 20:45:25 +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 4KCVmX3XF9z2xC6 for ; Tue, 8 Mar 2022 20:44:59 +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 1nRWOF-0004l1-EX; Tue, 08 Mar 2022 10:44:23 +0100 Message-ID: Date: Tue, 8 Mar 2022 10:44:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 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> <579eab10-594c-d6b2-0ddb-ea6ab8e02856@pengutronix.de> <117facba-ba33-349d-1085-25315cc1ae92@gmail.com> <9621c512-06f2-17b2-5c68-943b1f0981eb@gmail.com> From: Ahmad Fatoum In-Reply-To: <9621c512-06f2-17b2-5c68-943b1f0981eb@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, On 06.03.22 16:49, Tokunori Ikegami wrote: > Hi, > > On 2022/03/04 20:11, Ahmad Fatoum wrote: >> Hello Tokunori-san, >> >> On 20.02.22 13:22, Tokunori Ikegami wrote: >>> Hi Ahmad-san, >>> >>> Could you please try the version 2 patch attached for the error case? >>> This version is to check the DQ true data 0xFF by chip_good(). >> I had a similar patch locally as well at first. I just tested yours >> and I can't reproduce the issue. > Thanks for your support. > Sorry if possible could you please retest the attached the patch again since this fixed the version 1 patch maintainer review comments? Works good. Tested-by: Ahmad Fatoum >>> But I am not sure if this works or not since the error is possible to be caused by Hi-Z 0xff on floating bus or etc. >> That it works for me could be because of Hi-Z 0xff, which is why >> decided against it. > I see. >> >>>>>>> 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? >>>> I just mentioned about the actual issue behaviors as not worked chip_good() on S29GL964N and not worked chip_ready() on MX29GL512FHT2I-11G before etc. >>>> Anyway let me recheck the data sheet details as just checked it again quickly but needed more investigation to understand. >>> As far as I checked still both chip_good() and chip_ready() seem correct but still the root cause is unknown. >>> If as you mentioned the issue was cased by the DQ true data 0xFF I am not sure why the read work without any error after the write operation. >>> Also if the error was caused by the Hi-Z 0xff on floating bus as mentioned I am not sure why the read work without any error after the write operation with chip_ready(). >>> Sorry anyway the root cause is also unknown when the write operation was changed to use chip_good() instead of chip_ready(). >> I've be ok with v1 then. Restores working behavior for me and shouldn't break others. > > Noted but still I am thinking the version 2 patch to check 0xff seems better than to use chip_ready() so let me consider this again later. The original version has less room for surprise as it restores previously working behavior. Assuming 0xFF to be good without backing from documentation is more risky IMO. Thanks for your continued support, Ahmad > > Regards, > Ikegami > >> >> Cheers and thanks again, >> Ahmad >> >>> Regards, >>> Ikegami >>> >>>> Regards, >>>> Ikegami >>>> >>>>> 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 | 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 B5C39C43217 for ; Tue, 8 Mar 2022 09:49:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=u915J8vIzS/ijfZ8rUNS0upwC9l3AD840lIr2gXgl1U=; b=EV5TMgaJmY97uE wOKsELIEgrWtfQCmZl88H2sTS6cInLHpiRhYKsxuN+siBI38C65e5oEwXdwrvENGsUYUtaPMsAvnh SceI4DZM2WPGzxXjcFFOCp4qwVEaar0dwBFkJ2TgTIbz5CJrBCEeYSYxs6JLDVi88oKRea/CVhlkq bAk4CAlNq5bpYePh+xR7wBpPyILxsPvqMp8vv4+sNi8wiQjX5v8VPiQJ/OFRKdG3rv3ECH0RciXDR x8kNK7szfZc/XVn4geynbot/0CEgI4Zqlu/KvBDQFp0RmwuaCuicEy9TV4p4JqT2I9+YmYTczNeyQ w4g2QBXo3/FPOPsAPL7g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRWSi-003c2u-P6; Tue, 08 Mar 2022 09:49:01 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRWOJ-003Zx2-Qy for linux-mtd@lists.infradead.org; Tue, 08 Mar 2022 09:44:29 +0000 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 1nRWOF-0004l1-EX; Tue, 08 Mar 2022 10:44:23 +0100 Message-ID: Date: Tue, 8 Mar 2022 10:44:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 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" Cc: Chris Packham , Brian Norris , David Woodhouse , marek.vasut@gmail.com, cyrille.pitchen@wedev4u.fr, "linux-kernel@vger.kernel.org" , Pengutronix Kernel Team , linuxppc-dev@lists.ozlabs.org References: <3dbbcee5-81fc-cdf5-9f8b-b6ccb95beddc@pengutronix.de> <0f2cfcac-83ca-51a9-f92c-ff6495dca1d7@gmail.com> <66ee55d9-4f20-6722-6097-e53c2108ea07@gmail.com> <579eab10-594c-d6b2-0ddb-ea6ab8e02856@pengutronix.de> <117facba-ba33-349d-1085-25315cc1ae92@gmail.com> <9621c512-06f2-17b2-5c68-943b1f0981eb@gmail.com> From: Ahmad Fatoum In-Reply-To: <9621c512-06f2-17b2-5c68-943b1f0981eb@gmail.com> 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: linux-mtd@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220308_014427_949471_C9BAC788 X-CRM114-Status: GOOD ( 30.76 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org Hello Tokunori, On 06.03.22 16:49, Tokunori Ikegami wrote: > Hi, > > On 2022/03/04 20:11, Ahmad Fatoum wrote: >> Hello Tokunori-san, >> >> On 20.02.22 13:22, Tokunori Ikegami wrote: >>> Hi Ahmad-san, >>> >>> Could you please try the version 2 patch attached for the error case? >>> This version is to check the DQ true data 0xFF by chip_good(). >> I had a similar patch locally as well at first. I just tested yours >> and I can't reproduce the issue. > Thanks for your support. > Sorry if possible could you please retest the attached the patch again since this fixed the version 1 patch maintainer review comments? Works good. Tested-by: Ahmad Fatoum >>> But I am not sure if this works or not since the error is possible to be caused by Hi-Z 0xff on floating bus or etc. >> That it works for me could be because of Hi-Z 0xff, which is why >> decided against it. > I see. >> >>>>>>> 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? >>>> I just mentioned about the actual issue behaviors as not worked chip_good() on S29GL964N and not worked chip_ready() on MX29GL512FHT2I-11G before etc. >>>> Anyway let me recheck the data sheet details as just checked it again quickly but needed more investigation to understand. >>> As far as I checked still both chip_good() and chip_ready() seem correct but still the root cause is unknown. >>> If as you mentioned the issue was cased by the DQ true data 0xFF I am not sure why the read work without any error after the write operation. >>> Also if the error was caused by the Hi-Z 0xff on floating bus as mentioned I am not sure why the read work without any error after the write operation with chip_ready(). >>> Sorry anyway the root cause is also unknown when the write operation was changed to use chip_good() instead of chip_ready(). >> I've be ok with v1 then. Restores working behavior for me and shouldn't break others. > > Noted but still I am thinking the version 2 patch to check 0xff seems better than to use chip_ready() so let me consider this again later. The original version has less room for surprise as it restores previously working behavior. Assuming 0xFF to be good without backing from documentation is more risky IMO. Thanks for your continued support, Ahmad > > Regards, > Ikegami > >> >> Cheers and thanks again, >> Ahmad >> >>> Regards, >>> Ikegami >>> >>>> Regards, >>>> Ikegami >>>> >>>>> 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 | ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/