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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 4499 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]