Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2113847pxm; Fri, 4 Mar 2022 09:36:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJybjcN82s5be0QgrVecu4DGILkFVYWlkIitWQYbJlZawZ/o4wdbHkMS4ppemMbcOtbvcr1J X-Received: by 2002:a17:906:d49:b0:6b6:1f07:fb76 with SMTP id r9-20020a1709060d4900b006b61f07fb76mr31723238ejh.704.1646415405038; Fri, 04 Mar 2022 09:36:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646415405; cv=none; d=google.com; s=arc-20160816; b=fwPkcJOjbXiz6ca4h1a1recof7jY1oTCn8yuE1pHqeoKhTrx9NCZFUAjza092pDjP7 WkCVgP761ewTMp3aGvyO0fWYAFiMQboTXxdfHLfGbjbFTtlV9nCLd6QDgBAnwwvQFgkh BiHs7hmlB9CgStSHeinbNeJYFQwi7hoH4ivjJwcVs8278Wo5cn/a1C5xYsHW9poCd6z5 TTqzXj79j/sZgbJARPZ+g3AHdAwoqpS/RUsEj/vvO3T5yH4lN0zoJNklzAgNlGuv1f68 ZvrY5rI/2mow6/HeSnt7fvW9h5OTsEs88gMCCGTUNw3TcfpZf40XF+TfyKK8Q5tQddyS +okQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=hayUf98jL9FiQlY1T0ZFMe4JNg6GszK66qR1EYExf/4=; b=pOtOAIpJu0DkOBvV2ZhPa/5KfXLtHAOTNyRHZDCRQoIvKigwOwfzgRIB73LBnmI1pB xYW/NRWxEQ3vQ3bCySbW9EWqE8l3QrFnfVgGMMEycUNmDOR2gqlbQCEDBBXrogyWCRK4 hF9TxGJxNK7m72uOm5kmoS8u2cy/vpdMU8v2O/6hIXu1HNIgOc96jV/w6OoPdw7JJ/wq +Q3O24a0SzEWzOrYD/zReQLEcnd7s81hysO8I/E3I6Fdibe6VMTCyS4+eyaQim83nC+N TM43W7DP5lxXjega938gh7CMACBMkTS6rvKO7p2/usmvP8ZZmvhaGVwrzeL3Iy1gu9lU eHYg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nc2-20020a1709071c0200b006da2904819asi4599075ejc.887.2022.03.04.09.36.20; Fri, 04 Mar 2022 09:36:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236253AbiCDLMz (ORCPT + 99 others); Fri, 4 Mar 2022 06:12:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58764 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234098AbiCDLMy (ORCPT ); Fri, 4 Mar 2022 06:12:54 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07C33184B42 for ; Fri, 4 Mar 2022 03:12:06 -0800 (PST) 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 1nQ5qW-0000S2-O5; Fri, 04 Mar 2022 12:11:40 +0100 Message-ID: Date: Fri, 4 Mar 2022 12:11:32 +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> From: Ahmad Fatoum In-Reply-To: <117facba-ba33-349d-1085-25315cc1ae92@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: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. >>>>> 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. 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 |