[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a5c147b-e531-4aa3-8439-1b80d8ed7747@salutedevices.com>
Date: Fri, 26 Jan 2024 21:46:33 +0300
From: Martin Kurbanov <mmkurbanov@...utedevices.com>
To: Ezra Buehler <ezra@...yb.ch>, <linux-mtd@...ts.infradead.org>
CC: Chuanhong Guo <gch981213@...il.com>, Dmitry Rokosov
<ddrokosov@...rdevices.ru>, Martin Kurbanov <mmkurbanov@...rdevices.ru>, Md
Sadre Alam <quic_mdalam@...cinc.com>, Miquel Raynal
<miquel.raynal@...tlin.com>, Richard Weinberger <richard@....at>, Sridharan S
N <quic_sridsn@...cinc.com>, Vignesh Raghavendra <vigneshr@...com>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] mtd: spinand: Add support for 5-byte IDs
On 25.01.2024 23:01, Ezra Buehler wrote:
> From: Ezra Buehler <ezra.buehler@...qvarnagroup.com>
>
> 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@...qvarnagroup.com>
Tested for F50L1G41LB
Reviewed-by: Martin Kurbanov <mmkurbanov@...utedevices.com>
Tested-by: Martin Kurbanov <mmkurbanov@...utedevices.com>
> ---
> 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
--
Best Regards,
Martin Kurbanov
Powered by blists - more mailing lists