Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing
result") introduced some kind of regression with parser on subpartitions
where if a parser emits an error then the entire parsing process from the
upper parser fails and partitions are deleted.

Not checking for error in subpartitions was originally intended as
special parser can emit error also in the case of the partition not
correctly init (for example a wiped partition) or special case where the
partition should be skipped due to some ENV variables externally
provided (from bootloader for example)

One example case is the TRX partition where, in the context of a wiped
partition, returns a -ENOENT as the trx_magic is not found in the
expected TRX header (as the partition is wiped)

To better handle this and still keep some kind of error tracking (for
example to catch -ENOMEM errors or -EINVAL errors), permit parser on
subpartition to emit -ENOENT error, print a debug log and skip them
accordingly.

This results in giving better tracking of the status of the parser
(instead of returning just 0, dropping any kind of signal that there is
something wrong with the parser) and to some degree restore the original
logic of the subpartitions parse.

(worth to notice that some special partition might have all the special
header present for the parser and declare 0 partition in it, this is why
it would be wrong to simply return 0 in the case of a special partition
that is NOT init for the scanning parser)

Cc: stable@vger.kernel.org
Fixes: 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing result")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 drivers/mtd/mtdpart.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 994e8c51e674..2876501a7814 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -425,9 +425,12 @@ int add_mtd_partitions(struct mtd_info *parent,
 
 		mtd_add_partition_attrs(child);
 
-		/* Look for subpartitions */
+		/* Look for subpartitions (skip if no maching parser found) */
 		ret = parse_mtd_partitions(child, parts[i].types, NULL);
-		if (ret < 0) {
+		if (ret < 0 && ret == -ENOENT) {
+			pr_debug("Skip parsing subpartitions: %d\n", ret);
+			continue;
+		} else if (ret < 0) {
 			pr_err("Failed to parse subpartitions: %d\n", ret);
 			goto err_del_partitions;
 		}
-- 
2.51.0

On Sun, 09 Nov 2025 12:52:44 +0100, Christian Marangi wrote:
> Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing
> result") introduced some kind of regression with parser on subpartitions
> where if a parser emits an error then the entire parsing process from the
> upper parser fails and partitions are deleted.
> 
> Not checking for error in subpartitions was originally intended as
> special parser can emit error also in the case of the partition not
> correctly init (for example a wiped partition) or special case where the
> partition should be skipped due to some ENV variables externally
> provided (from bootloader for example)
> 
> [...]

Applied to mtd/next, thanks!

[1/1] mtd: mtdpart: ignore error -ENOENT from parsers on subpartitions
      commit: 64ef5f454e167bb66cf70104f033c3d71e6ef9c0

Patche(s) should be available on mtd/linux.git and will be
part of the next PR (provided that no robot complains by then).

Kind regards,
Miquèl

Hi Christian,

On 09/11/2025 at 12:52:44 +01, Christian Marangi <ansuelsmth@gmail.com> wrote:

> Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing
> result") introduced some kind of regression with parser on subpartitions
> where if a parser emits an error then the entire parsing process from the
> upper parser fails and partitions are deleted.
>
> Not checking for error in subpartitions was originally intended as
> special parser can emit error also in the case of the partition not
> correctly init (for example a wiped partition) or special case where the
> partition should be skipped due to some ENV variables externally
> provided (from bootloader for example)
>
> One example case is the TRX partition where, in the context of a wiped
> partition, returns a -ENOENT as the trx_magic is not found in the
> expected TRX header (as the partition is wiped)

I didn't had in mind this was a valid case. I am a bit puzzled because
it opens the breach to other special cases, but at the same time I have
no strong arguments to refuse this situation so let's go for it.

Thanks,
Miquèl

On Wed, Nov 12, 2025 at 10:33:25AM +0100, Miquel Raynal wrote:
> Hi Christian,
> 
> On 09/11/2025 at 12:52:44 +01, Christian Marangi <ansuelsmth@gmail.com> wrote:
> 
> > Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing
> > result") introduced some kind of regression with parser on subpartitions
> > where if a parser emits an error then the entire parsing process from the
> > upper parser fails and partitions are deleted.
> >
> > Not checking for error in subpartitions was originally intended as
> > special parser can emit error also in the case of the partition not
> > correctly init (for example a wiped partition) or special case where the
> > partition should be skipped due to some ENV variables externally
> > provided (from bootloader for example)
> >
> > One example case is the TRX partition where, in the context of a wiped
> > partition, returns a -ENOENT as the trx_magic is not found in the
> > expected TRX header (as the partition is wiped)
> 
> I didn't had in mind this was a valid case. I am a bit puzzled because
> it opens the breach to other special cases, but at the same time I have
> no strong arguments to refuse this situation so let's go for it.
> 

Thanks a lot for accepting this. I checked all the parser both upstream
and downstream and I found this ""undocumented"" pattern of returning
-ENOENT. [1] [2] [3]

For sure it's a regression, we had various device on OpenWrt that broke
from migrating from 6.6 to 6.12. I agree there is the risk you are
pointing out but I feel this is a good compromise to restore original
functionality of the upstream parsers.

(the other error condition are -ENOMEM or sometimes -EINVAL for parser
header present but very wrong)

[1] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/tplink_safeloader.c#L93
[2] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/scpart.c#L170
[3] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/ofpart_bcm4908.c#L47

-- 
	Ansuel

On 12/11/2025 at 10:43:17 +01, Christian Marangi <ansuelsmth@gmail.com> wrote:

> On Wed, Nov 12, 2025 at 10:33:25AM +0100, Miquel Raynal wrote:
>> Hi Christian,
>> 
>> On 09/11/2025 at 12:52:44 +01, Christian Marangi <ansuelsmth@gmail.com> wrote:
>> 
>> > Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing
>> > result") introduced some kind of regression with parser on subpartitions
>> > where if a parser emits an error then the entire parsing process from the
>> > upper parser fails and partitions are deleted.
>> >
>> > Not checking for error in subpartitions was originally intended as
>> > special parser can emit error also in the case of the partition not
>> > correctly init (for example a wiped partition) or special case where the
>> > partition should be skipped due to some ENV variables externally
>> > provided (from bootloader for example)
>> >
>> > One example case is the TRX partition where, in the context of a wiped
>> > partition, returns a -ENOENT as the trx_magic is not found in the
>> > expected TRX header (as the partition is wiped)
>> 
>> I didn't had in mind this was a valid case. I am a bit puzzled because
>> it opens the breach to other special cases, but at the same time I have
>> no strong arguments to refuse this situation so let's go for it.
>> 
>
> Thanks a lot for accepting this. I checked all the parser both upstream
> and downstream and I found this ""undocumented"" pattern of returning
> -ENOENT. [1] [2] [3]
>
> For sure it's a regression, we had various device on OpenWrt that broke
> from migrating from 6.6 to 6.12. I agree there is the risk you are
> pointing out but I feel this is a good compromise to restore original
> functionality of the upstream parsers.
>
> (the other error condition are -ENOMEM or sometimes -EINVAL for parser
> header present but very wrong)
>
> [1] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/tplink_safeloader.c#L93
> [2] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/scpart.c#L170
> [3] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/ofpart_bcm4908.c#L47

Thanks for the digging. I will apply this to -next and not -fixes. It
will be slightly longer to get it backported, but this gives a bit more
time for this patch to be thought about as I plan on sending my fixes PR
in the next days.

Miquèl