If you don't specify buswidth 2 (16 bits) in the device tree, FSMC doesn't even probe anymore:
fsmc-nand 10100000.flash: FSMC device partno 090, manufacturer 80, revision 00, config 00 nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 nand: ST Micro 10100000.flash nand: bus width 8 instead of 16 bits nand: No NAND device found fsmc-nand 10100000.flash: probe with driver fsmc-nand failed with error -22
With this patch to use autodetection unless buswidth is specified, the device is properly detected again:
fsmc-nand 10100000.flash: FSMC device partno 090, manufacturer 80, revision 00, config 00 nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 nand: ST Micro NAND 128MiB 1,8V 16-bit nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 fsmc-nand 10100000.flash: Using 1-bit HW ECC scheme Scanning device for bad blocks
I don't know where or how this happened, I think some change in the nand core.
Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij linus.walleij@linaro.org --- drivers/mtd/nand/raw/fsmc_nand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c index df61db8ce466593d533e617c141a8d2498b3a180..154fd9bea3016b2fa7fa720a41ef9eeed6063fd5 100644 --- a/drivers/mtd/nand/raw/fsmc_nand.c +++ b/drivers/mtd/nand/raw/fsmc_nand.c @@ -879,7 +879,9 @@ static int fsmc_nand_probe_config_dt(struct platform_device *pdev, } else if (val != 1) { dev_err(&pdev->dev, "invalid bank-width %u\n", val); return -EINVAL; - } + }; + } else { + nand->options |= NAND_BUSWIDTH_AUTO; }
if (of_property_read_bool(np, "nand-skip-bbtscan"))
--- base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585 change-id: 20250914-fsmc-bd18e1a8116f
Best regards,
Hi Linus,
On 14/09/2025 at 00:35:37 +02, Linus Walleij linus.walleij@linaro.org wrote:
If you don't specify buswidth 2 (16 bits) in the device tree, FSMC doesn't even probe anymore:
fsmc-nand 10100000.flash: FSMC device partno 090, manufacturer 80, revision 00, config 00 nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 nand: ST Micro 10100000.flash nand: bus width 8 instead of 16 bits nand: No NAND device found fsmc-nand 10100000.flash: probe with driver fsmc-nand failed with error -22
With this patch to use autodetection unless buswidth is specified, the device is properly detected again:
fsmc-nand 10100000.flash: FSMC device partno 090, manufacturer 80, revision 00, config 00 nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 nand: ST Micro NAND 128MiB 1,8V 16-bit nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 fsmc-nand 10100000.flash: Using 1-bit HW ECC scheme Scanning device for bad blocks
I don't know where or how this happened, I think some change in the nand core.
I had a look and honnestly could not find where we broke this. Could it be possible that it never worked with DT probing and only with platform data? Any idea of what was the previously working base?
Anyhow, this is just curiosity, patch is relevant (just a little nit below?).
Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij linus.walleij@linaro.org
drivers/mtd/nand/raw/fsmc_nand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c index df61db8ce466593d533e617c141a8d2498b3a180..154fd9bea3016b2fa7fa720a41ef9eeed6063fd5 100644 --- a/drivers/mtd/nand/raw/fsmc_nand.c +++ b/drivers/mtd/nand/raw/fsmc_nand.c @@ -879,7 +879,9 @@ static int fsmc_nand_probe_config_dt(struct platform_device *pdev, } else if (val != 1) { dev_err(&pdev->dev, "invalid bank-width %u\n", val); return -EINVAL;
}
};
^ There is a spurious ';' here, no?
- } else {
nand->options |= NAND_BUSWIDTH_AUTO;
Thanks, Miquèl
On Tue, Sep 16, 2025 at 11:33 AM Miquel Raynal miquel.raynal@bootlin.com wrote:
On 14/09/2025 at 00:35:37 +02, Linus Walleij linus.walleij@linaro.org wrote:
I don't know where or how this happened, I think some change in the nand core.
I had a look and honnestly could not find where we broke this. Could it be possible that it never worked with DT probing and only with platform data? Any idea of what was the previously working base?
I tested old kernels back to 4.20 and it didn't work. Probably it never worked?
I tried to recompile something further back but I don't have the required old toolchains around :P
Anyhow, this is just curiosity, patch is relevant (just a little nit below?).
};^There is a spurious ';' here, no?
Fixed in v2, also made a more elaborate handling if someone would explicitly set the width to 2.
I think the SPEAr that is the primary user always sets the width to 2 so they never saw this bug.
Yours, Linus Walleij
On 16/09/2025 at 20:49:25 +02, Linus Walleij linus.walleij@linaro.org wrote:
On Tue, Sep 16, 2025 at 11:33 AM Miquel Raynal miquel.raynal@bootlin.com wrote:
On 14/09/2025 at 00:35:37 +02, Linus Walleij linus.walleij@linaro.org wrote:
I don't know where or how this happened, I think some change in the nand core.
I had a look and honnestly could not find where we broke this. Could it be possible that it never worked with DT probing and only with platform data? Any idea of what was the previously working base?
I tested old kernels back to 4.20 and it didn't work. Probably it never worked?
Ah :-) Might make sense!
I tried to recompile something further back but I don't have the required old toolchains around :P
Yeah, no pb. As you said, we probably never faced the issue even though it was latent.
Anyhow, this is just curiosity, patch is relevant (just a little nit below?).
};^There is a spurious ';' here, no?
Fixed in v2, also made a more elaborate handling if someone would explicitly set the width to 2.
I think the SPEAr that is the primary user always sets the width to 2 so they never saw this bug.
Certainly.
Thanks! Miquèl
linux-stable-mirror@lists.linaro.org
-
Linus Walleij -
Miquel Raynal