Re: [RFH] SPI and SPI-NOR patch help

[Miquel Raynal <miquel.raynal@bootlin.com>]

On 18/02/2026 at 14:20:56 GMT, Peter Robinson <pbrobinson@gmail.com> wrote:

> On Wed, 18 Feb 2026 at 13:40, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>>
>> Hello Tom,
>>
>> On 16/02/2026 at 09:31:10 -06, Tom Rini <trini@konsulko.com> wrote:
>>
>> > On Mon, Feb 16, 2026 at 09:21:55AM +0100, Michael Walle wrote:
>> >> On Sat Feb 14, 2026 at 7:58 PM CET, Conor Dooley wrote:
>> >> > On Fri, Feb 13, 2026 at 10:46:07AM -0600, Tom Rini wrote:
>> >> >> Hey all,
>> >> >>
>> >> >> To be blunt, U-Boot needs help with reviewing and maintaining the SPI
>> >> >> and SPI-NOR subsystems. We haven't had someone with time to actively
>> >> >> work in this area for some time. I'm going through the outstanding
>> >> >> changes now, but it also seems a common problem is that with respect to
>> >> >> device IDs, most of the new ones also aren't in the upstream Linux
>> >> >> Kernel. Is there some better and generic solution we're missing so that
>> >> >> we don't have large and often growing device ID tables? I'd rather not
>> >> >> make that problem worse, so I've rejected two of those types of updates
>> >> >> today and I'm just setting aside a large number of others.
>> >> >
>> >> > Dunno if your timing was cursed on sending this, but Tudor submitted his
>> >> > resignation from spi-nor maintainership in the kernel about 10 mins
>> >> > after.
>> >> > I think Michael Walle might be responsible for what you're talking about
>> >> > here, with his 773bbe1044973 ("mtd: spi-nor: add generic flash driver"),
>> >> > but idk jack about spi-nor stuff.
>> >>
>> >> Yeah. Nowadays SPI-NOR flashes come with self describing tables,
>> >> which are already supported by u-boot, I think. The only change that
>> >> seems to be missing is the fallback to it if an id isn't found in
>> >> the flashdb. Only thing is, the SFDP doesn't describe all features,
>> >> most prominent example being locking. So if you need that, you'll
>> >> still need to have an entry per flash.
>> >>
>> >> In fact, in linux I'm planning to change to make it probe SFDP first
>> >> and then amend it with the flashdb information (if there is an
>> >> entry).
>> >
>> > Thanks for explaining. So in that U-Boot does have SFDP support, the
>> > first thing is platforms should likely be enabling that instead of just
>> > adding IDs, at least for basic support.
>>
>> Yes. There will be the need for IDs anyways, for those "extra" "non
>> sfdp" features, but that should reduce the load. For example, shall we
>> consider block protection in U-Boot or not? This is a useful feature,
>> but at the same time, do we really need it in a Bootloader? This is open
>> to discussion.
>
> By block protection do you mean for features like rpmc counters for
> rollback protection? If so I suspect there's some usefulness to
> supporting it given U-Boot ends up being the entry point for FW stack
> updates using mechanisms like UEFI capsule support.

Sounds like a legitimate use case. I was actually referring to Software
Block Protection bits (BP, TB, INV).

Thanks,
Miquèl