diff options
| author | Ezra Buehler <ezra.buehler@husqvarnagroup.com> | 2024-01-25 22:01:07 +0200 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2024-04-03 15:11:52 +0200 |
| commit | 41cae7275d9bff7eb1507025cb28d7d980314962 (patch) | |
| tree | 6fb86616da4ea45db58eab7f974805e683f16718 | |
| parent | 2b10a0a8e724c232490fd924032935d8d665e0be (diff) | |
| download | linux-stable-41cae7275d9bff7eb1507025cb28d7d980314962.tar.gz linux-stable-41cae7275d9bff7eb1507025cb28d7d980314962.tar.bz2 linux-stable-41cae7275d9bff7eb1507025cb28d7d980314962.zip | |
mtd: spinand: Add support for 5-byte IDs
commit 34a956739d295de6010cdaafeed698ccbba87ea4 upstream.
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).
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
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| -rw-r--r-- | include/linux/mtd/spinand.h | 2 |
1 files changed, 1 insertions, 1 deletions
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 |