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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B08FDC433EF for ; Fri, 15 Jul 2022 07:55:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232254AbiGOHzC (ORCPT ); Fri, 15 Jul 2022 03:55:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232262AbiGOHzC (ORCPT ); Fri, 15 Jul 2022 03:55:02 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C52537D790 for ; Fri, 15 Jul 2022 00:55:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id C5FA3CE2D7B for ; Fri, 15 Jul 2022 07:54:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D776C34115; Fri, 15 Jul 2022 07:54:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1657871696; bh=82nfuAmhSsviwae5A0o3DEoZ+dx2+ZJjOgTLcfthSQE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=yGJnEV3FcZZ596SM+iCFty1RInY52h1CIZo+0BxbXNkEnway6WhW/Y1fj4eEpYFJa 3y5hoWGOerzY3f3ZeUKgh6/JX54FEc5iCzDk+36zxwJ4AWtWPah15oM18gU3a98XKl ZNtVOBaLjCN5YjFqjqNi2HaZSYL7XUUMWNHH/yVM= Date: Fri, 15 Jul 2022 09:54:53 +0200 From: Greg Kroah-Hartman To: Sascha Hauer Cc: Tomasz =?utf-8?Q?Mo=C5=84?= , linux-mtd@lists.infradead.org, Miquel Raynal , Richard Weinberger , Sasha Levin , Linus Torvalds , Han Xu , kernel@pengutronix.de, stable@vger.kernel.org, k.drobinski@camlintechnologies.com Subject: Re: [PATCH] mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times Message-ID: References: <20220701110341.3094023-1-s.hauer@pengutronix.de> <20220715074631.GA7333@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Fri, Jul 15, 2022 at 09:54:10AM +0200, Greg Kroah-Hartman wrote: > On Fri, Jul 15, 2022 at 09:46:31AM +0200, Sascha Hauer wrote: > > On Fri, Jul 15, 2022 at 07:49:40AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Jul 15, 2022 at 07:27:02AM +0200, Tomasz Moń wrote: > > > > On Mon, 2022-07-11 at 11:12 +0200, Tomasz Moń wrote: > > > > > On Fri, 2022-07-01 at 13:03 +0200, Sascha Hauer wrote: > > > > > > 06781a5026350 Fixes the calculation of the DEVICE_BUSY_TIMEOUT register > > > > > > value from busy_timeout_cycles. busy_timeout_cycles is calculated wrong > > > > > > though: It is calculated based on the maximum page read time, but the > > > > > > timeout is also used for page write and block erase operations which > > > > > > require orders of magnitude bigger timeouts. > > > > > > > > > > > > Fix this by calculating busy_timeout_cycles from the maximum of > > > > > > tBERS_max and tPROG_max. > > > > > > > > > > 06781a5026350 was merged in v5.19-rc4 and then was picked up by several > > > > > stable kernels, including v5.15.51. After we have upgraded to v5.15.51 > > > > > we have observed the issue that Sascha mentioned in his email [1]. > > > > > > > > > > As the v5.19-rc6 was released yesterday and this fix is still not > > > > > applied, the v5.19-rc6 (and all stable kernels that picked up the > > > > > backport) causes NAND flash data loss on imx targets. > > > > > > > > > > I have backported this patch to our internal v5.15.51 based kernel on > > > > > 4th July 2022 and I can confirm that it does indeed solve the NAND data > > > > > loss on imx targets. > > > > > > > > > > Is it possible for this patch to make it to the v5.19-rc7? > > > > > > > > No response, so sending the email to more people so the voice is heard. > > > > Sorry if this is not the proper way, but I think the issue is serious. > > > > > > > > Current prepatch kernels starting with v5.19-rc4 and stable kernels > > > > starting with v5.4.202. v5.10.127, v5.15.51, v5.18.8 contain a > > > > "[PATCH] [REALLY REALLY BROKEN] mtd: rawnand: gpmi: Fix setting busy timeout setting" > > > > that is wreaking havoc to i.MX[678] or i.MX28 devices with NAND > > > > "** THIS PATCH WILL CAUSE DATA LOSS ON YOUR NAND!! **" [1] > > > > > > > > The solution is to either: > > > > * Revert 06781a5026350 ("mtd: rawnand: gpmi: Fix setting busy timeout > > > > setting") and all its cherry-picks to stable branches, *OR* > > > > * Apply the fix ("mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout > > > > based on program/erase times") [2] > > > > > > > > Please do whatever you see fit. > > > > > > I can do do a stable release with this reverted, but I really expected > > > to see the fix in linux-next by now at the very least. Does this driver > > > not have an active maintainer and subsystem maintainer for some reason? > > > > My IRC history doesn't go back far enough, but if I recall correctly > > Miquel is on vacation, he would have picked up this patch for linux-next > > otherwise. > > Ok, let me do a round of stable releases so that people don't get hit by > this now... > > Hopefully this gets fixed up by 5.19-final. Note, one way this could get fixed up sooner if it was reported to the regression bot, as Linus and other subsystem maintainers do monitor that and will pick up patches that are dropped like this one. thanks, greg k-h