From: "Michael Walle" <mwalle@kernel.org>
To: "A. Zini" <alessandro.zini@siemens.com>, <linux-mtd@lists.infradead.org>
Cc: "Tudor Ambarus" <tudor.ambarus@linaro.org>,
"Pratyush Yadav" <pratyush@kernel.org>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>
Subject: Re: [PATCH 1/3] mtd: spi-nor: handle JEDEC manufacturer bank
Date: Mon, 05 Aug 2024 11:18:47 +0200 [thread overview]
Message-ID: <D37V6QTQZM50.2I613FUEQIWXG@kernel.org> (raw)
In-Reply-To: <20240729102016.8527-2-alessandro.zini@siemens.com>
[-- Attachment #1.1: Type: text/plain, Size: 1660 bytes --]
Hi,
> JEDEC JEP106 maintains a list of manufacturers IDs, consisting in 7
> bit of information plus 1 parity bit, for a total of 1 Byte. Since the
> number of manufacturers is way larger than this, JEDEC additionally
> defines the continuation code 0x7f to be used as a prefix to the
> actual ID, subdividing IDs in different banks.
>
> This commit handles such manufacturer bank code by introducing a new
> mfr_bank field in flash_info struct. This field is intended to be
> populated when specifying a manufacturer part, and for retro
> compatibility it is assumed to be 1 if omitted.
> Note that this assumption was already implicitly taken, as only a
> couple of the already supported manufacturer parts have the
> continuation code prefixed to the actual ID.
>
> Given the fast expanding pace of JEP106, the read ID operation has
> been expanded to 128 Bytes plus the pre-existing 6 Bytes for the ID
> code, thus supporting up to 128 banks.
Quick remarks without having looked deeper into this patch.
I really don't like issuing a 128byte command for older flashes. So
maybe we can just stick to the 6 bytes and if that's not enough we
can use the extended format.
I'd like to keep the .id as the primary index. This will now
introduce a mfr_bank, so the unique key will be (mfr_bank,id). Can
we somehow encode the continuation codes into the id itself? E.g.
we know the manufacturer ID is always < 127. Honestly, I'm not sure
this is the way to go as we know flash manufacturers sometimes don't
care. So right now, we just compare the .id with whats returned by
the RDID command without interpreting it.
-michael
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2024-08-05 9:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 10:20 [PATCH 0/3] Add support for Cypress/Infineon cy15b102q A. Zini
2024-07-29 10:20 ` [PATCH 1/3] mtd: spi-nor: handle JEDEC manufacturer bank A. Zini
2024-08-05 9:18 ` Michael Walle [this message]
2024-08-07 13:37 ` A. Zini
2024-08-08 8:38 ` Michael Walle
2024-07-29 10:20 ` [PATCH 2/3] mtd: spi-nor: convert existing devices to use mfr_bank A. Zini
2024-07-29 10:20 ` [PATCH 3/3] mtd: spi-nor: add support for Cypress cy15b102q A. Zini
2024-08-05 9:08 ` [PATCH 0/3] Add support for Cypress/Infineon cy15b102q Michael Walle
2024-08-07 12:31 ` A. Zini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D37V6QTQZM50.2I613FUEQIWXG@kernel.org \
--to=mwalle@kernel.org \
--cc=alessandro.zini@siemens.com \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=tudor.ambarus@linaro.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.