From: sashiko-bot@kernel.org
To: "James Hilliard" <james.hilliard1@gmail.com>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Brian Norris" <computersforpeace@gmail.com>,
"Boris Brezillon" <bbrezillon@kernel.org>,
"Arseniy Krasnov" <AVKrasnov@sberdevices.ru>,
"Chen-Yu Tsai" <wens@kernel.org>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Samuel Holland" <samuel@sholland.org>,
"Thomas Gleixner" <tglx@kernel.org>,
"Vitaly Wool" <vitalywool@gmail.com>,
"David Woodhouse" <dwmw2@infradead.org>,
"Russell King" <rmk+kernel@arm.linux.org.uk>,
"David Woodhouse" <David.Woodhouse@intel.com>,
"Mike Rapoport" <rppt@kernel.org>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"Christophe Kerello" <christophe.kerello@st.com>,
"Jason Roberts" <jason.e.roberts@intel.com>,
"Michal Simek" <michal.simek@amd.com>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Mason Yang" <masonccyang@mxic.com.tw>,
"Ramuthevar Vadivel Murugan"
<vadivel.muruganx.ramuthevar@linux.intel.com>,
"Stefan Agner" <stefan@agner.ch>, "Lucas Stach" <dev@lynxeye.de>,
"Thierry Reding" <thierry.reding@kernel.org>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Dmitry Osipenko" <digetx@gmail.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Jorge Ramirez-Ortiz" <jorge.ramirez@oss.qualcomm.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Yifeng Zhao" <yifeng.zhao@rock-chips.com>,
"Nicolas Ferre" <nicolas.ferre@microchip.com>,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Claudiu Beznea" <claudiu.beznea@tuxon.dev>,
"Keguang Zhang" <keguang.zhang@gmail.com>,
"Jacky Huang" <ychuang3@nuvoton.com>,
"Shan-Chun Hung" <schung@nuvoton.com>,
"Frank Li" <Frank.Li@nxp.com>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Fabio Estevam" <festevam@gmail.com>, "Han Xu" <han.xu@nxp.com>,
"Liang Yang" <liang.yang@amlogic.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Kevin Hilman" <khilman@baylibre.com>,
"Jerome Brunet" <jbrunet@baylibre.com>,
"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Kamal Dasu" <kamal.dasu@broadcom.com>,
"Broadcom internal kernel review list"
<bcm-kernel-feedback-list@broadcom.com>,
"Vladimir Zapolskiy" <vz@mleia.com>,
"Piotr Wojtaszczyk" <piotr.wojtaszczyk@timesys.com>,
"Paul Cercueil" <paul@crapouillou.net>,
"Harvey Hunt" <harveyhuntnexus@gmail.com>,
"Maxim Levitsky" <maximlevitsky@gmail.com>,
"Michael Walle" <michael@walle.cc>,
"Srinivas Kandagatla" <srini@kernel.org>
Cc: "Tze Yee Ng" <tze.yee.ng@altera.com>,
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
Subject: Re: [PATCH 18/58] mtd: rawnand: atmel: retain chips across controller removal
Date: Sat, 07 Nov 2026 20:31:28 +0000 [thread overview]
Message-ID: <sashiko-outbox-203294@kernel.org> (raw)
In-Reply-To: <20261107-submit-rawnand-retained-handle-lifetime-v1-v1-18-0181ef0cc4c8@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] mtd: rawnand: atmel: initialize __free(kfree) variables at
declaration
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [High] mtd: rawnand: atmel: unclocked register access in
atmel_nfc_interrupt() [1]
--
commit b77082ebe154b5b59053fa6c8fd897f19a5685b6
Author: James Hilliard <james.hilliard1@gmail.com>
mtd: rawnand: atmel: retain chips across controller removal
This commit retains NAND chip and controller allocations until all MTD
references are released and disconnects chips before tearing down controller
resources.
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
> index 0bdbcbb50d94c..10b725fa61d86 100644
> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
[ ... ]
> @@ -1638,7 +1640,7 @@ static struct atmel_nand *atmel_nand_create(struct atmel_nand_controller *nc,
> struct device_node *np,
> int reg_cells)
> {
> - struct atmel_nand *nand;
> + struct atmel_nand *nand __free(kfree) = NULL;
> struct gpio_desc *gpio;
> int numcs, ret, i;
>
> @@ -1649,7 +1651,7 @@ static struct atmel_nand *atmel_nand_create(struct atmel_nand_controller *nc,
> return ERR_PTR(-EINVAL);
> }
>
> - nand = devm_kzalloc(nc->dev, struct_size(nand, cs, numcs), GFP_KERNEL);
> + nand = kzalloc(struct_size(nand, cs, numcs), GFP_KERNEL);
> if (!nand)
> return ERR_PTR(-ENOMEM);
[ ... ]
> @@ -1791,7 +1809,7 @@ atmel_nand_controller_legacy_add_nands(struct atmel_nand_controller *nc)
> {
> struct device *dev = nc->dev;
> struct platform_device *pdev = to_platform_device(dev);
> - struct atmel_nand *nand;
> + struct atmel_nand *nand __free(kfree) = NULL;
> struct gpio_desc *gpio;
> struct resource *res;
>
> @@ -1799,7 +1817,7 @@ atmel_nand_controller_legacy_add_nands(struct atmel_nand_controller *nc)
> * Legacy bindings only allow connecting a single NAND with a unique CS
> * line to the controller.
> */
> - nand = devm_kzalloc(nc->dev, struct_size(nand, cs, 1), GFP_KERNEL);
> + nand = kzalloc(struct_size(nand, cs, 1), GFP_KERNEL);
> if (!nand)
> return -ENOMEM;
[Severity: Low]
This isn't a bug, but per the Cleanup API conventions in
include/linux/cleanup.h, __free() variables should be defined and
initialized in a single statement at their allocation point rather than
declared as "= NULL" at the top of atmel_nand_create() and
atmel_nand_controller_legacy_add_nands() and assigned later.
[ ... ]
> @@ -2349,6 +2366,11 @@ atmel_hsmc_nand_controller_remove(struct atmel_nand_controller *nc)
> return 0;
> }
>
> +static void atmel_hsmc_nand_controller_release(struct nand_controller *controller)
> +{
> + kfree(to_hsmc_nand_controller(controller));
> +}
> +
> static int atmel_hsmc_nand_controller_probe(struct platform_device *pdev,
> const struct atmel_nand_controller_caps *caps)
> {
> @@ -2356,9 +2378,13 @@ static int atmel_hsmc_nand_controller_probe(struct platform_device *pdev,
> struct atmel_hsmc_nand_controller *nc;
> int ret;
>
> - nc = devm_kzalloc(dev, sizeof(*nc), GFP_KERNEL);
> + nc = kzalloc_obj(*nc);
> if (!nc)
> return -ENOMEM;
> + ret = devm_nand_controller_init(dev, &nc->base.base,
> + atmel_hsmc_nand_controller_release);
> + if (ret)
> + return ret;
[Severity: High]
This problem wasn't introduced by this patch, but can atmel_nfc_interrupt()
perform an unclocked register read during teardown [1]?
atmel_hsmc_nand_controller_probe() registers atmel_nfc_interrupt() with
devm_request_irq(..., IRQF_SHARED, ...), while
atmel_hsmc_nand_controller_remove() manually disables hsmc_nc->clk before
devres releases the IRQ:
drivers/mtd/nand/raw/atmel/nand-controller.c:atmel_hsmc_nand_controller_remove() {
...
if (hsmc_nc->clk) {
clk_disable_unprepare(hsmc_nc->clk);
clk_put(hsmc_nc->clk);
}
...
}
CPU0 CPU1
atmel_hsmc_nand_controller_remove()
clk_disable_unprepare(hsmc_nc->clk)
<shared IRQ fires>
atmel_nfc_interrupt()
regmap_read(..., ATMEL_HSMC_NFC_SR, ...)
<-- unclocked register access
<devres cleanup>
devm_irq_release()
If another device on the shared IRQ line raises an interrupt before devres
frees the handler, reading ATMEL_HSMC_NFC_SR with the clock disabled can
trigger a synchronous external abort.
[1] https://sashiko.dev/#/bug/linux-94d27cd6-f6fe-452a-863e-36cbb87e9adc
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261107-submit-rawnand-retained-handle-lifetime-v1-v1-0-0181ef0cc4c8@gmail.com?part=18
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2026-11-07 20:31 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 10:15 [PATCH 00/58] mtd: rawnand: retain chip and controller state across removal James Hilliard
2026-11-07 10:15 ` [PATCH 01/58] mtd: clear OTP provider pointers after unregistering them James Hilliard
2026-11-07 20:21 ` sashiko-bot
2026-11-07 10:15 ` [PATCH 02/58] nvmem: retain provider context through final device release James Hilliard
2026-11-07 20:26 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 03/58] mtd: add opt-in lifetime ownership for backing objects James Hilliard
2026-11-07 20:50 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 04/58] mtd: rawnand: separate hardware disconnection from cleanup James Hilliard
2026-11-07 20:42 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 05/58] mtd: rawnand: share retained chip and controller ownership James Hilliard
2026-11-07 10:16 ` [PATCH 06/58] mtd: rawnand: macronix: serialize OTP access with NAND operations James Hilliard
2026-11-07 10:16 ` [PATCH 07/58] mtd: rawnand: sunxi: retain chip state until the final MTD put James Hilliard
2026-11-07 10:16 ` [PATCH 08/58] mtd: rawnand: plat_nand: retain open-handle state on removal James Hilliard
2026-11-07 10:16 ` [PATCH 09/58] mtd: rawnand: gpio: " James Hilliard
2026-11-07 10:16 ` [PATCH 10/58] mtd: rawnand: stm32_fmc2: " James Hilliard
2026-11-07 10:16 ` [PATCH 11/58] mtd: rawnand: denali: retain chips across controller removal James Hilliard
2026-11-07 20:25 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 12/58] mtd: rawnand: arasan: " James Hilliard
2026-11-07 10:16 ` [PATCH 13/58] mtd: rawnand: mxic: retain open-handle state on removal James Hilliard
2026-11-07 10:16 ` [PATCH 14/58] mtd: rawnand: intel: " James Hilliard
2026-11-07 20:31 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 15/58] mtd: rawnand: tegra: " James Hilliard
2026-11-07 20:32 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 16/58] mtd: rawnand: mtk: retain chips across controller removal James Hilliard
2026-11-07 10:16 ` [PATCH 17/58] mtd: rawnand: rockchip: " James Hilliard
2026-11-07 10:16 ` [PATCH 18/58] mtd: rawnand: atmel: " James Hilliard
2026-11-07 20:31 ` sashiko-bot [this message]
2026-11-07 10:16 ` [PATCH 19/58] mtd: rawnand: orion: retain open-handle state on removal James Hilliard
2026-11-07 20:29 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 20/58] mtd: rawnand: socrates: " James Hilliard
2026-11-07 10:16 ` [PATCH 21/58] mtd: rawnand: fsl_upm: " James Hilliard
2026-11-07 10:16 ` [PATCH 22/58] mtd: rawnand: pasemi: " James Hilliard
2026-11-07 10:16 ` [PATCH 23/58] mtd: rawnand: ams-delta: " James Hilliard
2026-11-07 10:16 ` [PATCH 24/58] mtd: rawnand: xway: " James Hilliard
2026-11-07 10:16 ` [PATCH 27/58] mtd: rawnand: technologic: " James Hilliard
2026-11-07 10:16 ` [PATCH 28/58] mtd: rawnand: loongson: " James Hilliard
2026-11-07 10:16 ` [PATCH 29/58] mtd: rawnand: ma35d1: " James Hilliard
2026-11-07 10:16 ` [PATCH 30/58] mtd: rawnand: pl35x: " James Hilliard
2026-11-07 10:16 ` [PATCH 31/58] mtd: rawnand: mxc: " James Hilliard
2026-11-07 10:16 ` [PATCH 32/58] mtd: rawnand: fsmc: " James Hilliard
2026-11-07 10:16 ` [PATCH 33/58] mtd: rawnand: gpmi: " James Hilliard
2026-11-07 10:16 ` [PATCH 34/58] mtd: rawnand: omap2: " James Hilliard
2026-11-07 10:16 ` [PATCH 35/58] mtd: rawnand: marvell: " James Hilliard
2026-11-07 10:16 ` [PATCH 36/58] mtd: rawnand: renesas: " James Hilliard
2026-11-07 10:16 ` [PATCH 37/58] mtd: rawnand: meson: " James Hilliard
2026-11-07 10:16 ` [PATCH 38/58] mtd: rawnand: cadence: " James Hilliard
2026-11-07 10:16 ` [PATCH 39/58] mtd: rawnand: qcom: " James Hilliard
2026-11-07 20:47 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 40/58] mtd: rawnand: cafe: " James Hilliard
2026-11-07 10:16 ` [PATCH 41/58] mtd: rawnand: brcmnand: " James Hilliard
2026-11-07 10:16 ` [PATCH 42/58] mtd: rawnand: au1550nd: retain chip state across removal James Hilliard
2026-11-07 20:44 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 43/58] mtd: rawnand: sharpsl: " James Hilliard
2026-11-07 10:16 ` [PATCH 44/58] mtd: rawnand: davinci: " James Hilliard
2026-11-07 10:16 ` [PATCH 45/58] mtd: rawnand: sh_flctl: " James Hilliard
2026-11-07 10:16 ` [PATCH 46/58] mtd: rawnand: lpc32xx_slc: " James Hilliard
2026-11-07 10:16 ` [PATCH 47/58] mtd: rawnand: lpc32xx_mlc: " James Hilliard
2026-11-07 10:16 ` [PATCH 48/58] mtd: rawnand: ndfc: " James Hilliard
2026-11-07 10:16 ` [PATCH 49/58] mtd: rawnand: txx9ndfmc: " James Hilliard
2026-11-07 10:16 ` [PATCH 50/58] mtd: rawnand: ingenic: " James Hilliard
2026-11-07 10:16 ` [PATCH 51/58] mtd: rawnand: mpc5121: " James Hilliard
2026-11-07 20:48 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 52/58] mtd: rawnand: bcm47xxnflash: " James Hilliard
2026-11-07 10:16 ` [PATCH 53/58] mtd: rawnand: fsl_elbc: " James Hilliard
2026-11-07 10:16 ` [PATCH 54/58] mtd: rawnand: fsl_ifc: " James Hilliard
2026-11-07 10:16 ` [PATCH 55/58] mtd: rawnand: r852: " James Hilliard
2026-11-07 20:59 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 56/58] mtd: rawnand: nandsim: " James Hilliard
2026-11-07 20:52 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 57/58] mtd: rawnand: cs553x: " James Hilliard
2026-11-07 10:16 ` [PATCH 58/58] mtd: rawnand: diskonchip: " James Hilliard
2026-11-07 19:33 ` [PATCH 25/58] mtd: rawnand: hisi504: retain open-handle state on removal James Hilliard
2026-11-07 19:33 ` [PATCH 26/58] mtd: rawnand: vf610: " James Hilliard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-203294@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=AVKrasnov@sberdevices.ru \
--cc=David.Woodhouse@intel.com \
--cc=Frank.Li@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bbrezillon@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=boris.brezillon@collabora.com \
--cc=christophe.kerello@st.com \
--cc=claudiu.beznea@tuxon.dev \
--cc=computersforpeace@gmail.com \
--cc=dev@lynxeye.de \
--cc=digetx@gmail.com \
--cc=dwmw2@infradead.org \
--cc=festevam@gmail.com \
--cc=han.xu@nxp.com \
--cc=harveyhuntnexus@gmail.com \
--cc=heiko@sntech.de \
--cc=imx@lists.linux.dev \
--cc=james.hilliard1@gmail.com \
--cc=jason.e.roberts@intel.com \
--cc=jbrunet@baylibre.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=jorge.ramirez@oss.qualcomm.com \
--cc=kamal.dasu@broadcom.com \
--cc=keguang.zhang@gmail.com \
--cc=kernel@pengutronix.de \
--cc=khilman@baylibre.com \
--cc=liang.yang@amlogic.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=mani@kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=masonccyang@mxic.com.tw \
--cc=matthias.bgg@gmail.com \
--cc=maximlevitsky@gmail.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=michael@walle.cc \
--cc=michal.simek@amd.com \
--cc=miquel.raynal@bootlin.com \
--cc=neil.armstrong@linaro.org \
--cc=nicolas.ferre@microchip.com \
--cc=paul@crapouillou.net \
--cc=piotr.wojtaszczyk@timesys.com \
--cc=richard@nod.at \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=rppt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=samuel@sholland.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=schung@nuvoton.com \
--cc=srini@kernel.org \
--cc=stefan@agner.ch \
--cc=tglx@kernel.org \
--cc=thierry.reding@kernel.org \
--cc=tze.yee.ng@altera.com \
--cc=vadivel.muruganx.ramuthevar@linux.intel.com \
--cc=vigneshr@ti.com \
--cc=vitalywool@gmail.com \
--cc=vz@mleia.com \
--cc=wens@kernel.org \
--cc=wsa+renesas@sang-engineering.com \
--cc=ychuang3@nuvoton.com \
--cc=yifeng.zhao@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®