From: Ezra Buehler ezra.buehler@husqvarnagroup.com
[ 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: stable@vger.kernel.org # 6.6.23 Cc: stable@vger.kernel.org # 6.7.11 Cc: stable@vger.kernel.org # 6.8.2 Signed-off-by: Ezra Buehler ezra.buehler@husqvarnagroup.com Reviewed-by: Martin Kurbanov mmkurbanov@salutedevices.com Tested-by: Martin Kurbanov mmkurbanov@salutedevices.com Signed-off-by: Miquel Raynal miquel.raynal@bootlin.com Link: https://lore.kernel.org/linux-mtd/20240125200108.24374-2-ezra@easyb.ch Signed-off-by: Dmitry Rokosov ddrokosov@salutedevices.com ---
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/20240125200108.24374-1-ezra@easyb.ch/
--- 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
On Thu, Apr 04, 2024 at 03:15:21PM +0300, Dmitry Rokosov wrote:
From: Ezra Buehler ezra.buehler@husqvarnagroup.com
[ 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: stable@vger.kernel.org # 6.6.23 Cc: stable@vger.kernel.org # 6.7.11 Cc: stable@vger.kernel.org # 6.8.2 Signed-off-by: Ezra Buehler ezra.buehler@husqvarnagroup.com Reviewed-by: Martin Kurbanov mmkurbanov@salutedevices.com Tested-by: Martin Kurbanov mmkurbanov@salutedevices.com Signed-off-by: Miquel Raynal miquel.raynal@bootlin.com Link: https://lore.kernel.org/linux-mtd/20240125200108.24374-2-ezra@easyb.ch Signed-off-by: Dmitry Rokosov ddrokosov@salutedevices.com
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 ezra.buehler@husqvarnagroup.com
[ 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: stable@vger.kernel.org # 6.6.23 Cc: stable@vger.kernel.org # 6.7.11 Cc: stable@vger.kernel.org # 6.8.2 Signed-off-by: Ezra Buehler ezra.buehler@husqvarnagroup.com Reviewed-by: Martin Kurbanov mmkurbanov@salutedevices.com Tested-by: Martin Kurbanov mmkurbanov@salutedevices.com Signed-off-by: Miquel Raynal miquel.raynal@bootlin.com Link: https://lore.kernel.org/linux-mtd/20240125200108.24374-2-ezra@easyb.ch Signed-off-by: Dmitry Rokosov ddrokosov@salutedevices.com
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!
linux-stable-mirror@lists.linaro.org
-
Dmitry Rokosov -
Greg KH