From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794083496; b=n3XQBYJcq2ch03VFxq//DAO/tKJc/Ksg1V+7DYp4Tc+6F6BGD9B23Xrx1s+MeSYzp2K1 S5liuZNkInsOZZsDFW5LqJOQwEpxaHhYdEpEbo5L8TmENkuuzs+T1D4LSYf+SOo95CYTB rI77rqhLSpqoz2M5G8VYY7WduTU1dRWQ9y3QfjsOsZhiR2teDYDXwXL6dpAZZ9ErBWGJq vFVTmSVmpEq0fl4U0ooYjkb/E3RshO6tTGZz9gsjYmr6PwxBoaDD0Gu10QV1YDhCskaLT tiDX8RlupnPRD8Fug29TDS24udM+tL3cMwPBi8rGKKI38qnKE0cDqdu3ye792wKX2qg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794083496; h=Received:DKIM-Signature:Message-ID:From:Subject:Reply-To:To:Cc: In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=uVfYL/crgHpwOKUheIhGq2v1ptnfI5IGAlA37cvNCeM=; b=CMTKuI/sT/zXMQtg1OGHjDnAY1nGildOT36zA/DUAYkj8yum8gn8b1j7AChWZITFgcwF /S8k3JMp5zupZGJytIIdcBWDFjGXKt0pHArWOFMhsZoQDtmkN1Hcdii1vg2fU0Npr//Wc u58VVgAFvsNlY7HVex5yT9lUIwvCkZ1ecxwGy1DYshD7Fs1qF3zLDUzCBvGg42s6+mtEa sU/qKnTEqHXAvqH5CPfoA6ReEoDt9aky7rlNatP7TYJH15vP4e2O1IvIZielh2WTF1f+h lo6UiNBMT6dk9gFhTVMN0doqyUVIjeri2qItH0tHUx34lIyatGZnbN6BdDQuIOSYCqw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=WQmQRM64; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87017606A32D; Sat, 7 Nov 2026 20:31:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=WQmQRM64 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70A051F008BD; Sat, 7 Nov 2026 20:31:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794083496; bh=uVfYL/crgHpwOKUheIhGq2v1ptnfI5IGAlA37cvNCeM=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=WQmQRM64W6hKVHx476szHYttXvElu2yKjqim0wVAyHoli4626joyKYUgVYMqtaADH 1QBuB/kEEowdmnTQc+aEdpRB38EG5zEeYEnfcjjnK3h9Nn8POX2ggl5NPn2bmDUfFJ SoUr1BE8TTsvuiEPz1w23DBvxmA0xMYYMZmD88gnv6xcMN+oM4IGs2lp1DRVin/FTu v4lQ2UV4OmH7jnotAuqn68sfH95q0tJtLTLaRVF3UnBagrJLfY9G0CKltXhi1JZNoh paXuaFhFVZ7wEAC9WDZyXIeFRTSqDGbPqzUSSNhOpCW+7IQSTaLXpD4AiVkgAPN7Hs PzVimKFWPkKiA== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH 14/58] mtd: rawnand: intel: retain open-handle state on removal Reply-To: sashiko-reviews@lists.linux.dev To: "James Hilliard" , "Miquel Raynal" , "Richard Weinberger" , "Vignesh Raghavendra" , "Brian Norris" , "Boris Brezillon" , "Arseniy Krasnov" , "Chen-Yu Tsai" , "Jernej Skrabec" , "Samuel Holland" , "Thomas Gleixner" , "Vitaly Wool" , "David Woodhouse" , "Russell King" , "David Woodhouse" , "Mike Rapoport" , "Maxime Coquelin" , "Alexandre Torgue" , "Christophe Kerello" , "Jason Roberts" , "Michal Simek" , "Boris Brezillon" , "Mason Yang" , "Ramuthevar Vadivel Murugan" , "Stefan Agner" , "Lucas Stach" , "Thierry Reding" , "Jonathan Hunter" , "Dmitry Osipenko" , "Matthias Brugger" , "AngeloGioacchino Del Regno" , "Jorge Ramirez-Ortiz" , "Heiko Stuebner" , "Yifeng Zhao" , "Nicolas Ferre" , "Alexandre Belloni" , "Claudiu Beznea" , "Keguang Zhang" , "Jacky Huang" , "Shan-Chun Hung" , "Frank Li" , "Sascha Hauer" , "Pengutronix Kernel Team" , "Fabio Estevam" , "Han Xu" , "Liang Yang" , "Neil Armstrong" , "Kevin Hilman" , "Jerome Brunet" , "Martin Blumenstingl" , "Manivannan Sadhasivam" , "Kamal Dasu" , "Broadcom internal kernel review list" , "Vladimir Zapolskiy" , "Piotr Wojtaszczyk" , "Paul Cercueil" , "Harvey Hunt" , "Maxim Levitsky" , "Michael Walle" , "Srinivas Kandagatla" Cc: "Tze Yee Ng" , linux-mtd@lists.infradead.org, linux-sunxi@lists.linux.dev, imx@lists.linux.dev, linux-amlogic@lists.infradead.org, Frank.Li@kernel.org, wsa+renesas@sang-engineering.com In-Reply-To: <20261107-submit-rawnand-retained-handle-lifetime-v1-v1-14-0181ef0cc4c8@gmail.com> References: <20261107-submit-rawnand-retained-handle-lifetime-v1-v1-0-0181ef0cc4c8@gmail.com> <20261107-submit-rawnand-retained-handle-lifetime-v1-v1-14-0181ef0cc4c8@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 07 Nov 2026 20:31:33 +0000 X-Mailing-List: imx@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Thank you for your contribution! Sashiko AI review found no new issues in this patch, but noticed 1 related pre-existing issue it does not introduce: - [Medium] mtd: rawnand: intel: missing hardware disable in ebu_nand_probe() [1] -- commit 42115b2b815dc0a43fa249f1ae95d7eeefbb02a5 Author: James Hilliard mtd: rawnand: intel: retain open-handle state on removal This commit disconnects NAND operations on removal and ties the lifetime of the Intel EBU NAND controller and chip state to the last MTD reference. > diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/n= and/raw/intel-nand-controller.c > index 477a427dac1f0..e4a24e69ebbcf 100644 > --- a/drivers/mtd/nand/raw/intel-nand-controller.c > +++ b/drivers/mtd/nand/raw/intel-nand-controller.c [ ... ] > @@ -692,9 +699,15 @@ static int ebu_nand_probe(struct platform_device *pd= ev) > if (ret) > goto err_cleanup_dma; > =20 > - ret =3D mtd_device_register(mtd, NULL, 0); > + ret =3D nand_set_release(nand, NULL); > if (ret) > goto err_clean_nand; > + ret =3D mtd_device_register(mtd, NULL, 0); > + if (ret) { > + nand_disconnect(nand); > + mtd_put_master(mtd); > + goto err_cleanup_dma; > + } [Severity: Medium] This problem wasn't introduced by this patch, but if probe fails during or after nand_scan() [1], doesn't jumping to err_clean_nand or err_cleanup_dma leave EBU_CON_NANDM_EN enabled in EBU_CON? nand_scan() runs ebu_nand_exec_op() -> ebu_select_chip(), which enables the controller in EBU_CON, but unlike ebu_nand_remove(), the probe error paths never call ebu_nand_disable(&ebu_host->chip) before cleaning up DMA and returning. [1] https://sashiko.dev/#/bug/linux-34984827-527c-4bf7-baa8-10dffee6916d --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261107-submit-raw= nand-retained-handle-lifetime-v1-v1-0-0181ef0cc4c8@gmail.com?part=3D14