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 39/58] mtd: rawnand: qcom: retain open-handle state on removal
Date: Sat, 07 Nov 2026 20:47:28 +0000 [thread overview]
Message-ID: <sashiko-outbox-203326@kernel.org> (raw)
In-Reply-To: <20261107-submit-rawnand-retained-handle-lifetime-v1-v1-39-0181ef0cc4c8@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mtd: rawnand: qcom: broken error handling in
qcom_probe_nand_devices()
--
commit 0a9084cf5fec792ff4833fe6c2d5c8f9780c60a1
Author: James Hilliard <james.hilliard1@gmail.com>
mtd: rawnand: qcom: retain open-handle state on removal
This commit ties the lifetime of qcom_nand_host and qcom_nand_controller to
the MTD and NAND controller release callbacks, validates boot partitions
before registering MTD devices, and adds cleanup of registered chips on
probe failure and removal.
> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
> index 2d98f79b492d6..f812de1d776fc 100644
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
[ ... ]
> @@ -2077,15 +2091,13 @@ static int qcom_probe_nand_devices(struct qcom_nand_controller *nandc)
> int ret = -ENODEV;
>
> for_each_available_child_of_node_scoped(dn, child) {
> - host = devm_kzalloc(dev, sizeof(*host), GFP_KERNEL);
> + host = kzalloc_obj(*host);
> if (!host)
> return -ENOMEM;
>
> ret = qcom_nand_host_init_and_register(nandc, host, child);
> - if (ret) {
> - devm_kfree(dev, host);
> + if (ret)
> continue;
> - }
>
> list_add_tail(&host->node, &nandc->host_list);
> }
[Severity: Medium]
Should qcom_probe_nand_devices() return ret instead of continuing when
qcom_nand_host_init_and_register() fails?
Continuing the loop means that if an earlier child node fails (for example
with -EPROBE_DEFER or invalid boot partitions) and a later child succeeds,
ret is overwritten with 0 and the partial probe is not unwound via
err_setup.
Worse, if the earlier child fails in qcom_nand_attach_chip() when
qcom_alloc_bam_transaction() returns NULL after qcom_free_bam_transaction()
freed nandc->bam_txn:
drivers/mtd/nand/raw/qcom_nandc.c:qcom_nand_attach_chip() {
...
if (nandc->props->supports_bam)
qcom_free_bam_transaction(nandc);
nandc->max_cwperpage = max_t(unsigned int, nandc->max_cwperpage,
cwperpage);
/* Now allocate the BAM transaction based on updated max_cwperpage */
if (nandc->props->supports_bam) {
nandc->bam_txn = qcom_alloc_bam_transaction(nandc);
if (!nandc->bam_txn) {
dev_err(nandc->dev,
"failed to allocate bam transaction\n");
return -ENOMEM;
}
}
...
}
continuing to the next child node calls nand_scan(), which runs
qcom_clear_bam_transaction() and dereferences nandc->bam_txn while it is
NULL.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261107-submit-rawnand-retained-handle-lifetime-v1-v1-0-0181ef0cc4c8@gmail.com?part=39
WARNING: multiple messages have this Message-ID (diff)
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 39/58] mtd: rawnand: qcom: retain open-handle state on removal
Date: Sat, 07 Nov 2026 20:47:28 +0000 [thread overview]
Message-ID: <sashiko-outbox-203326@kernel.org> (raw)
In-Reply-To: <20261107-submit-rawnand-retained-handle-lifetime-v1-v1-39-0181ef0cc4c8@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mtd: rawnand: qcom: broken error handling in
qcom_probe_nand_devices()
--
commit 0a9084cf5fec792ff4833fe6c2d5c8f9780c60a1
Author: James Hilliard <james.hilliard1@gmail.com>
mtd: rawnand: qcom: retain open-handle state on removal
This commit ties the lifetime of qcom_nand_host and qcom_nand_controller to
the MTD and NAND controller release callbacks, validates boot partitions
before registering MTD devices, and adds cleanup of registered chips on
probe failure and removal.
> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
> index 2d98f79b492d6..f812de1d776fc 100644
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
[ ... ]
> @@ -2077,15 +2091,13 @@ static int qcom_probe_nand_devices(struct qcom_nand_controller *nandc)
> int ret = -ENODEV;
>
> for_each_available_child_of_node_scoped(dn, child) {
> - host = devm_kzalloc(dev, sizeof(*host), GFP_KERNEL);
> + host = kzalloc_obj(*host);
> if (!host)
> return -ENOMEM;
>
> ret = qcom_nand_host_init_and_register(nandc, host, child);
> - if (ret) {
> - devm_kfree(dev, host);
> + if (ret)
> continue;
> - }
>
> list_add_tail(&host->node, &nandc->host_list);
> }
[Severity: Medium]
Should qcom_probe_nand_devices() return ret instead of continuing when
qcom_nand_host_init_and_register() fails?
Continuing the loop means that if an earlier child node fails (for example
with -EPROBE_DEFER or invalid boot partitions) and a later child succeeds,
ret is overwritten with 0 and the partial probe is not unwound via
err_setup.
Worse, if the earlier child fails in qcom_nand_attach_chip() when
qcom_alloc_bam_transaction() returns NULL after qcom_free_bam_transaction()
freed nandc->bam_txn:
drivers/mtd/nand/raw/qcom_nandc.c:qcom_nand_attach_chip() {
...
if (nandc->props->supports_bam)
qcom_free_bam_transaction(nandc);
nandc->max_cwperpage = max_t(unsigned int, nandc->max_cwperpage,
cwperpage);
/* Now allocate the BAM transaction based on updated max_cwperpage */
if (nandc->props->supports_bam) {
nandc->bam_txn = qcom_alloc_bam_transaction(nandc);
if (!nandc->bam_txn) {
dev_err(nandc->dev,
"failed to allocate bam transaction\n");
return -ENOMEM;
}
}
...
}
continuing to the next child node calls nand_scan(), which runs
qcom_clear_bam_transaction() and dereferences nandc->bam_txn while it is
NULL.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261107-submit-rawnand-retained-handle-lifetime-v1-v1-0-0181ef0cc4c8@gmail.com?part=39
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
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 39/58] mtd: rawnand: qcom: retain open-handle state on removal
Date: Sat, 07 Nov 2026 20:47:28 +0000 [thread overview]
Message-ID: <sashiko-outbox-203326@kernel.org> (raw)
In-Reply-To: <20261107-submit-rawnand-retained-handle-lifetime-v1-v1-39-0181ef0cc4c8@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mtd: rawnand: qcom: broken error handling in
qcom_probe_nand_devices()
--
commit 0a9084cf5fec792ff4833fe6c2d5c8f9780c60a1
Author: James Hilliard <james.hilliard1@gmail.com>
mtd: rawnand: qcom: retain open-handle state on removal
This commit ties the lifetime of qcom_nand_host and qcom_nand_controller to
the MTD and NAND controller release callbacks, validates boot partitions
before registering MTD devices, and adds cleanup of registered chips on
probe failure and removal.
> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
> index 2d98f79b492d6..f812de1d776fc 100644
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
[ ... ]
> @@ -2077,15 +2091,13 @@ static int qcom_probe_nand_devices(struct qcom_nand_controller *nandc)
> int ret = -ENODEV;
>
> for_each_available_child_of_node_scoped(dn, child) {
> - host = devm_kzalloc(dev, sizeof(*host), GFP_KERNEL);
> + host = kzalloc_obj(*host);
> if (!host)
> return -ENOMEM;
>
> ret = qcom_nand_host_init_and_register(nandc, host, child);
> - if (ret) {
> - devm_kfree(dev, host);
> + if (ret)
> continue;
> - }
>
> list_add_tail(&host->node, &nandc->host_list);
> }
[Severity: Medium]
Should qcom_probe_nand_devices() return ret instead of continuing when
qcom_nand_host_init_and_register() fails?
Continuing the loop means that if an earlier child node fails (for example
with -EPROBE_DEFER or invalid boot partitions) and a later child succeeds,
ret is overwritten with 0 and the partial probe is not unwound via
err_setup.
Worse, if the earlier child fails in qcom_nand_attach_chip() when
qcom_alloc_bam_transaction() returns NULL after qcom_free_bam_transaction()
freed nandc->bam_txn:
drivers/mtd/nand/raw/qcom_nandc.c:qcom_nand_attach_chip() {
...
if (nandc->props->supports_bam)
qcom_free_bam_transaction(nandc);
nandc->max_cwperpage = max_t(unsigned int, nandc->max_cwperpage,
cwperpage);
/* Now allocate the BAM transaction based on updated max_cwperpage */
if (nandc->props->supports_bam) {
nandc->bam_txn = qcom_alloc_bam_transaction(nandc);
if (!nandc->bam_txn) {
dev_err(nandc->dev,
"failed to allocate bam transaction\n");
return -ENOMEM;
}
}
...
}
continuing to the next child node calls nand_scan(), which runs
qcom_clear_bam_transaction() and dereferences nandc->bam_txn while it is
NULL.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261107-submit-rawnand-retained-handle-lifetime-v1-v1-0-0181ef0cc4c8@gmail.com?part=39
_______________________________________________
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:47 UTC|newest]
Thread overview: 219+ 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 ` James Hilliard
2026-11-07 10:15 ` James Hilliard
2026-11-07 10:15 ` [PATCH 01/58] mtd: clear OTP provider pointers after unregistering them James Hilliard
2026-11-07 10:15 ` James Hilliard
2026-11-07 10:15 ` James Hilliard
2026-11-07 20:21 ` sashiko-bot
2026-11-07 20:21 ` sashiko-bot
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 10:15 ` James Hilliard
2026-11-07 10:15 ` James Hilliard
2026-11-07 20:26 ` sashiko-bot
2026-11-07 20:26 ` sashiko-bot
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 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:50 ` sashiko-bot
2026-11-07 20:50 ` sashiko-bot
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 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:42 ` sashiko-bot
2026-11-07 20:42 ` sashiko-bot
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 ` James Hilliard
2026-11-07 10:16 ` 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 ` James Hilliard
2026-11-07 10:16 ` 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 ` James Hilliard
2026-11-07 10:16 ` 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 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 09/58] mtd: rawnand: gpio: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 10/58] mtd: rawnand: stm32_fmc2: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 11/58] mtd: rawnand: denali: retain chips across controller removal James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:25 ` sashiko-bot
2026-11-07 20:25 ` sashiko-bot
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 ` James Hilliard
2026-11-07 10:16 ` 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 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 14/58] mtd: rawnand: intel: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:31 ` sashiko-bot
2026-11-07 20:31 ` sashiko-bot
2026-11-07 20:31 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 15/58] mtd: rawnand: tegra: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:32 ` sashiko-bot
2026-11-07 20:32 ` sashiko-bot
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 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 17/58] mtd: rawnand: rockchip: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 18/58] mtd: rawnand: atmel: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:31 ` sashiko-bot
2026-11-07 20:31 ` sashiko-bot
2026-11-07 20:31 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 19/58] mtd: rawnand: orion: retain open-handle state on removal James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:29 ` sashiko-bot
2026-11-07 20:29 ` sashiko-bot
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 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 21/58] mtd: rawnand: fsl_upm: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 22/58] mtd: rawnand: pasemi: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 23/58] mtd: rawnand: ams-delta: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 24/58] mtd: rawnand: xway: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 27/58] mtd: rawnand: technologic: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 28/58] mtd: rawnand: loongson: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 29/58] mtd: rawnand: ma35d1: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 30/58] mtd: rawnand: pl35x: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 31/58] mtd: rawnand: mxc: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 32/58] mtd: rawnand: fsmc: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 33/58] mtd: rawnand: gpmi: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 34/58] mtd: rawnand: omap2: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 35/58] mtd: rawnand: marvell: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 36/58] mtd: rawnand: renesas: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 37/58] mtd: rawnand: meson: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 38/58] mtd: rawnand: cadence: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 39/58] mtd: rawnand: qcom: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:47 ` sashiko-bot [this message]
2026-11-07 20:47 ` sashiko-bot
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 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 41/58] mtd: rawnand: brcmnand: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 42/58] mtd: rawnand: au1550nd: retain chip state across removal James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:44 ` sashiko-bot
2026-11-07 20:44 ` sashiko-bot
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 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 44/58] mtd: rawnand: davinci: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 45/58] mtd: rawnand: sh_flctl: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 46/58] mtd: rawnand: lpc32xx_slc: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 47/58] mtd: rawnand: lpc32xx_mlc: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 48/58] mtd: rawnand: ndfc: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 49/58] mtd: rawnand: txx9ndfmc: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 50/58] mtd: rawnand: ingenic: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 51/58] mtd: rawnand: mpc5121: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:48 ` sashiko-bot
2026-11-07 20:48 ` sashiko-bot
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 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 53/58] mtd: rawnand: fsl_elbc: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 54/58] mtd: rawnand: fsl_ifc: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 55/58] mtd: rawnand: r852: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:59 ` sashiko-bot
2026-11-07 20:59 ` sashiko-bot
2026-11-07 20:59 ` sashiko-bot
2026-11-07 10:16 ` [PATCH 56/58] mtd: rawnand: nandsim: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 20:52 ` sashiko-bot
2026-11-07 20:52 ` sashiko-bot
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 ` James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` [PATCH 58/58] mtd: rawnand: diskonchip: " James Hilliard
2026-11-07 10:16 ` James Hilliard
2026-11-07 10:16 ` 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 ` James Hilliard
2026-11-07 19:33 ` James Hilliard
2026-11-07 19:33 ` [PATCH 26/58] mtd: rawnand: vf610: " James Hilliard
2026-11-07 19:33 ` James Hilliard
2026-11-07 19:33 ` 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-203326@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.