Message ID | 20240404121532.14755-1-ddrokosov@salutedevices.com |
---|---|
State | New |
Headers | show |
Series | [v1] mtd: spinand: Add support for 5-byte IDs | expand |
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!
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