From: Michael Walle <mwalle@kernel.org>
To: liao jaime <jaimeliao.tw@gmail.com>
Cc: linux-mtd@lists.infradead.org, tudor.ambarus@linaro.org,
pratyush@kernel.org, miquel.raynal@bootlin.com,
leoyu@mxic.com.tw, JaimeLiao <jaimeliao@mxic.com.tw>
Subject: Re: [PATCH v3 2/5] mtd: spi-nor: core: Hook manufacture by checking first byte ID
Date: Fri, 11 Aug 2023 12:20:33 +0200 [thread overview]
Message-ID: <ab8e506ea941749b07f0a93565e731c0@kernel.org> (raw)
In-Reply-To: <CAAQoYRnpGmo4Li5fJoRWq6_C4cF+OdzbuvQKtiGDJL1HcChXvA@mail.gmail.com>
Hi,
>> >> This won't work beacuse the manufacturer id is not always
>> >> one byte long, think of continuation codes. In fact, as the
>> >> flash_info table is of now, we cannot even rely on the
>> >> continuation codes, but we have to always check for the
>> >> complete id_len, i.e. there is at least one hack where
>> >> the id is reversed and the manufacturer is the last byte,
>> >> iirc. some oddball cypress mram chip.
>> > According JEDEC standard, 1st byte is manufacture ID.
>> > I check id table, "cy15x104q" with multi manufacture ID in
>> > later bytes by RDID command(9F).
>>
>> Yes the currently supported cy15x104q is broken.. but nevertheless
>> it's there. Also some spansion flashes uses winbond manufacturer
>> ids.
> Ok, got it.
> I have a idea, create a member maybe name .check_vendor in
> spi_nor_manufacturer.
> A example, macronix_check_vendor function for checking this IC whether
> belong macronix or not.
> Each vendor could create their checking function for ID table didn't
> include that ID.
> Is it ok?
Honestly, I'm against adding that vendor discovery stuff to the
generic nor driver. What's the use case of it? You can just
read the ID from userspace and a tool there can decide which
flash it is.
-michael
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2023-08-11 10:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 9:54 [PATCH v3 0/5] Add octal DTR support for Macronix flash Jaime Liao
2023-08-04 9:54 ` [PATCH v3 1/5] mtd: spi-nor: add Octal " Jaime Liao
2023-08-07 6:44 ` Michael Walle
2023-08-04 9:54 ` [PATCH v3 2/5] mtd: spi-nor: core: Hook manufacture by checking first byte ID Jaime Liao
2023-08-07 6:37 ` Michael Walle
2023-08-09 1:04 ` liao jaime
2023-08-10 7:27 ` Michael Walle
2023-08-11 9:03 ` liao jaime
2023-08-11 10:11 ` Tudor Ambarus
2023-08-14 8:04 ` liao jaime
2023-08-11 10:20 ` Michael Walle [this message]
2023-08-14 8:24 ` liao jaime
2023-08-31 3:18 ` liao jaime
2023-09-04 14:54 ` Michael Walle
2023-08-04 9:54 ` [PATCH v3 3/5] spi: spi-mem: Allow specifying the byte order in DTR mode Jaime Liao
2023-08-07 6:40 ` Michael Walle
2023-08-09 1:36 ` liao jaime
2023-08-10 7:31 ` Michael Walle
2023-08-04 9:54 ` [PATCH v3 4/5] mtd: spi-nor: core: " Jaime Liao
2023-08-04 9:54 ` [PATCH v3 5/5] mtd: spi-nor: sfdp: Get the 8D-8D-8D byte order from BFPT Jaime Liao
2023-08-07 6:42 ` [PATCH v3 0/5] Add octal DTR support for Macronix flash Michael Walle
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=ab8e506ea941749b07f0a93565e731c0@kernel.org \
--to=mwalle@kernel.org \
--cc=jaimeliao.tw@gmail.com \
--cc=jaimeliao@mxic.com.tw \
--cc=leoyu@mxic.com.tw \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=tudor.ambarus@linaro.org \
/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.