On Wed, 18 Feb 2026 at 13:40, Miquel Raynal <[email protected]> wrote: > > Hello Tom, > > On 16/02/2026 at 09:31:10 -06, Tom Rini <[email protected]> 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. > > 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
