On Fri, Feb 20, 2026 at 09:35:50AM +0200, Tudor Ambarus wrote: > > > On 2/19/26 10:57 PM, Tom Rini wrote: > > On Thu, Feb 19, 2026 at 02:13:24PM +0200, Tudor Ambarus wrote: > >> Hi, > >> > >> + Pratush, > >> + Vignesh, > >> + Marek, > >> > >> On 2/18/26 11:23 AM, Miquel Raynal 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. > >> > >> Right. > >> > >> SFDP is behind a config, because of size constraints I assume. And then we > >> also have a tiny duplicate version of the driver for stricter size > >> constraints. Are these size constraints defined somewhere? We need to know > >> them in order to choose a direction. > >> > >> Also, I'd argue that having the tiny version of the driver was ideal. > >> Instead we should have tried to modularize SPI NOR, by SFDP, static > >> initialization of flashes, manufacturer drivers. > > > > Some platforms define their overall size constraints, and so we know for > > sure a hard limit even in full U-Boot. More platforms do this for SPL, > > but not all. So the general answer does end up being that we always care > > about if there is a more size-considerate solution with minimal > > trade-offs. Especially since we are also in a more minimal overall > > space. > > > > Thanks, Tom. I get this. I was curious about some numbers, but probably a > good reference is the size of spi-nor-tiny.o. My point is that if we try > to modularize the SPI NOR core we might get a chance to strip it to a > spi-nor-tiny equivalent. This would reduce code duplication and > maintenance cost. > > In what concerns the flash IDs array that keeps extending, that can be > indeed mitigated by implementing just the BFPT (Basic Flash Parameter > Table) from the SFDP (Serial FLash Discoverable Parameters) table. So for > SPL we would have a minimal core with a minimal SFDP (just BFPT or parts > of it) that can handle the basic support for all flashes that define BFPT. > We won't need to add new flash IDs for flashes where we want just basic > support. > > Unfortunately I currently don't work with MTDs so I'm not interested in > implementing what I'm suggesting.
Those are good suggestions that hopefully someone can pick up and implement, thanks! -- Tom
signature.asc
Description: PGP signature
