From: Ezra Buehler <[email protected]>
[ Upstream commit 34a956739d295de6010cdaafeed698ccbba87ea4 ]
E.g. ESMT chips will return an identification code with a length of 5
bytes. In order to prevent ambiguity, flash chips would actually need to
return IDs that are up to 17 or more bytes long due to JEDEC's
continuation scheme. I understand that if a manufacturer ID is located
in bank N of JEDEC's database (there are currently 16 banks), N - 1
continuation codes (7Fh) need to be added to the identification code
(comprising of manufacturer ID and device ID). However, most flash chip
manufacturers don't seem to implement this (correctly).
Cc: <[email protected]> # 6.6.23
Cc: <[email protected]> # 6.7.11
Cc: <[email protected]> # 6.8.2
Signed-off-by: Ezra Buehler <[email protected]>
Reviewed-by: Martin Kurbanov <[email protected]>
Tested-by: Martin Kurbanov <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
Signed-off-by: Dmitry Rokosov <[email protected]>
---
In the patch series [1] only one patch was marked with Fixes tag, that's
why the secon patch was not applied to 6.6.y, 6.7.y and 6.8y. It breaks
ESMT detection flow with logs:
[ 0.770730] spi-nand spi0.0: unknown raw ID c8017f7f
[ 0.772688] spi-nand: probe of spi0.0 failed with error -524
Please cherry-pick the second patch from the series to 6.6.y, 6.7.y and
6.8.y.
Links:
[1] https://lore.kernel.org/linux-mtd/[email protected]/
---
include/linux/mtd/spinand.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
index badb4c1ac079..5c19ead60499 100644
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -169,7 +169,7 @@
struct spinand_op;
struct spinand_device;
-#define SPINAND_MAX_ID_LEN 4
+#define SPINAND_MAX_ID_LEN 5
/*
* For erase, write and read operation, we got the following timings :
* tBERS (erase) 1ms to 4ms
--
2.43.0
On Thu, Apr 04, 2024 at 03:15:21PM +0300, Dmitry Rokosov wrote:
> From: Ezra Buehler <[email protected]>
>
> [ Upstream commit 34a956739d295de6010cdaafeed698ccbba87ea4 ]
This commit is already in the following releases:
6.6.24 6.7.12 6.8.3 6.9-rc1
> E.g. ESMT chips will return an identification code with a length of 5
> bytes. In order to prevent ambiguity, flash chips would actually need to
> return IDs that are up to 17 or more bytes long due to JEDEC's
> continuation scheme. I understand that if a manufacturer ID is located
> in bank N of JEDEC's database (there are currently 16 banks), N - 1
> continuation codes (7Fh) need to be added to the identification code
> (comprising of manufacturer ID and device ID). However, most flash chip
> manufacturers don't seem to implement this (correctly).
>
> Cc: <[email protected]> # 6.6.23
> Cc: <[email protected]> # 6.7.11
> Cc: <[email protected]> # 6.8.2
> Signed-off-by: Ezra Buehler <[email protected]>
> Reviewed-by: Martin Kurbanov <[email protected]>
> Tested-by: Martin Kurbanov <[email protected]>
> Signed-off-by: Miquel Raynal <[email protected]>
> Link: https://lore.kernel.org/linux-mtd/[email protected]
> Signed-off-by: Dmitry Rokosov <[email protected]>
> ---
>
> In the patch series [1] only one patch was marked with Fixes tag, that's
> why the secon patch was not applied to 6.6.y, 6.7.y and 6.8y. It breaks
> ESMT detection flow with logs:
>
> [ 0.770730] spi-nand spi0.0: unknown raw ID c8017f7f
> [ 0.772688] spi-nand: probe of spi0.0 failed with error -524
>
> Please cherry-pick the second patch from the series to 6.6.y, 6.7.y and
> 6.8.y.
What commit id is "the second patch" here? The one referenced above?
If so, again, this is already in a released kernel, so I'm confused as
to what to do here.
thanks,
greg k-h
On Fri, Apr 05, 2024 at 08:37:48AM +0200, Greg KH wrote:
> On Thu, Apr 04, 2024 at 03:15:21PM +0300, Dmitry Rokosov wrote:
> > From: Ezra Buehler <[email protected]>
> >
> > [ Upstream commit 34a956739d295de6010cdaafeed698ccbba87ea4 ]
>
> This commit is already in the following releases:
> 6.6.24 6.7.12 6.8.3 6.9-rc1
>
> > E.g. ESMT chips will return an identification code with a length of 5
> > bytes. In order to prevent ambiguity, flash chips would actually need to
> > return IDs that are up to 17 or more bytes long due to JEDEC's
> > continuation scheme. I understand that if a manufacturer ID is located
> > in bank N of JEDEC's database (there are currently 16 banks), N - 1
> > continuation codes (7Fh) need to be added to the identification code
> > (comprising of manufacturer ID and device ID). However, most flash chip
> > manufacturers don't seem to implement this (correctly).
> >
> > Cc: <[email protected]> # 6.6.23
> > Cc: <[email protected]> # 6.7.11
> > Cc: <[email protected]> # 6.8.2
> > Signed-off-by: Ezra Buehler <[email protected]>
> > Reviewed-by: Martin Kurbanov <[email protected]>
> > Tested-by: Martin Kurbanov <[email protected]>
> > Signed-off-by: Miquel Raynal <[email protected]>
> > Link: https://lore.kernel.org/linux-mtd/[email protected]
> > Signed-off-by: Dmitry Rokosov <[email protected]>
> > ---
> >
> > In the patch series [1] only one patch was marked with Fixes tag, that's
> > why the secon patch was not applied to 6.6.y, 6.7.y and 6.8y. It breaks
> > ESMT detection flow with logs:
> >
> > [ 0.770730] spi-nand spi0.0: unknown raw ID c8017f7f
> > [ 0.772688] spi-nand: probe of spi0.0 failed with error -524
> >
> > Please cherry-pick the second patch from the series to 6.6.y, 6.7.y and
> > 6.8.y.
>
> What commit id is "the second patch" here? The one referenced above?
> If so, again, this is already in a released kernel, so I'm confused as
> to what to do here.
Ah, I apologize for not checking versions 6.8.3 and 6.7.12. My test
environment was running on versions 6.8.2 and 6.7.11. Therefore, the
mistake was on my part. Please disregard the cherry-pick for those
versions, and thank you for quick reply!
--
Thank you,
Dmitry