archive mirror
 help / color / mirror / Atom feed
From: <>
To: <>, <>
Cc: <>, <>,
	<>, <>, <>,
Subject: Re: [PATCH] mtd: spi-nor: mt25qu: Ignore 6th ID byte
Date: Tue, 23 Nov 2021 16:14:43 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 11/23/21 4:01 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> Hi,
> Am 2021-11-23 13:40, schrieb Alexander Sverdlin:
>> On 23/11/2021 09:14, Michael Walle wrote:
>>>> Some people ask themselves why this table keeps growing if there is
>>>> SFDP...
>>>> I see the point in fixups, but maybe at some point we will be able to
>>>> support
>>>> some devices just out of the box?
>>> Are these features detectable by SFDP? Without knowing anything, as
>>> you ignored
>>> my former question, I'd say no.
>> Well, I just had nothing to say on your question.
>> It wasn't my intention to study security features of a chip, which I
>> don't use.
> Like I said, without that information its hard for me do decide if we
> can just
> ignore that last byte. (And yes I've already tried to get that NDA PDF
> via $WORK,
> but I don't have high hopes with that).

It would be nice to understand what is the difference between the two,
otherwise keeping a single flash entry will become a maintenance burden.
For example, what is the difference between the "top/bottom block address
protection lock" and the BIT(5) (Top/Bottom) of the Status Register?

Is the newer flash completely backward compatible with the 0x00 variant?
I'm not talking about the flash_info flags that are currently specified
in the flash_info entry, but about all the features of the 0x00 version
(also the ones that are not implemented in linux SPI NOR).

If the newer flash is fully backward compatible with the older one,
it should be fine to strip the 6th byte of ID. As Michael has suggested,
if the security features are not SFDP discoverable (either via a generic
table or a vendor specific table) and one wants to use/implement the
security features, one will have to revert the patch that drops the 6th
byte of ID, and to introduce a new flash_info entry anyway.

Linux MTD discussion mailing list

  reply	other threads:[~2021-11-23 16:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19  8:04 [PATCH] mtd: spi-nor: mt25qu: Ignore 6th ID byte Alexander A Sverdlin
2021-11-19 21:19 ` Michael Walle
2021-11-22  7:06   ` Alexander Sverdlin
2021-11-22 15:05     ` Michael Walle
2021-11-23  7:45       ` Alexander Sverdlin
2021-11-23  8:14         ` Michael Walle
2021-11-23 12:40           ` Alexander Sverdlin
2021-11-23 14:01             ` Michael Walle
2021-11-23 16:14               ` Tudor.Ambarus [this message]
2021-11-23 12:13       ` Alexander Sverdlin
2021-11-23 17:42         ` Pratyush Yadav
2021-11-25  7:26           ` Alexander Sverdlin
2021-11-30  9:49             ` Pratyush Yadav
2022-07-18 15:03 ` Tudor.Ambarus

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).