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

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

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.

> It still leaves us in a bad spot
> about having SPI and SPI-NOR stuff reviewed and maintained, but at least
> it's clearer in public now where it stands.

I guess spi-mem and SPI NAND is also in this kind of situation, even
with the Amarula crew doing what they can to improve the situation.

Thanks,
Miquèl