From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
Michael Walle <michael@walle.cc>
Cc: Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Pratyush Yadav <pratyush@kernel.org>,
linux-mtd@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v4] mtd: spi-nor: Add support for sst26vf032b flash
Date: Fri, 18 Aug 2023 13:06:56 +0300 [thread overview]
Message-ID: <d3707bc2-0163-5be3-0031-e27835da6012@linaro.org> (raw)
In-Reply-To: <20230808173059.5fbea615@xps-13>
On 08.08.2023 18:30, Miquel Raynal wrote:
> Hi Michael,
>
> michael@walle.cc wrote on Tue, 08 Aug 2023 10:35:08 +0200:
>
>> Hi,
>>
>>>> Mhh, this flash has vendor tables. The sst26vf global unlock should
>>>> be discoverable. There is a table with all supported opcodes, which
>>>> could be used to see whether this flash needs the global unlock.
>>>
>>> Is this logic already existing in the core?
>>
>> No unfortunately not.
>>
>>> Do you have a pointer?
>>
>> It seems that we'd need to have some kind of parser support for
>> vendor specific SFPD tables. Then look for the sst25vf family
>> and the availability of the global unlock command, if both is
>> satisfied, set the locking ops.
>
> Do you mind if we actually take that one which, on this regard should
> be absolutely identical to the existing 64b entry?
>
> If one ever brings the logic you described I'll be pleased to test it
> as long as I have the board.
>
I'm fine with it. For the moment these entries are not supper annoying
to maintain, but would be great if we use as much of the vendor tables
in the future if possible.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2023-08-18 10:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 7:50 [PATCH v4] mtd: spi-nor: Add support for sst26vf032b flash Miquel Raynal
2023-08-08 8:11 ` Michael Walle
2023-08-08 8:24 ` Miquel Raynal
2023-08-08 8:35 ` Michael Walle
2023-08-08 15:30 ` Miquel Raynal
2023-08-18 10:06 ` Tudor Ambarus [this message]
2023-08-18 10:07 ` 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:
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=d3707bc2-0163-5be3-0031-e27835da6012@linaro.org \
--to=tudor.ambarus@linaro.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=thomas.petazzoni@bootlin.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox