[RFH] SPI and SPI-NOR patch help

[Tom Rini]

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. 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260216/9a81e151/attachment.sig>