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

[<Takahiro.Kuwano@infineon.com>]

Hi,

> 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.
> 
> >
> > 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.
> 
> If you have write capability in u-boot, having block protection is useful
> to avoid inadvertent writes.
> 
> >
> >> 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.
> 
> Takahiro recently accepted becoming a designated reviewer for SPI NOR
> in Linux, and I think his expertise would be highly valuable in U-Boot
> as well. Takahiro, if you have the bandwidth, would you be open to
> becoming a designated reviewer here too? Or maybe see how things are
> going in Linux first? No pressure.
> 
Yes, I'm open to do that.

To sync with Linux, we need to isolate stacked/parallel support from core first.
https://patchwork.ozlabs.org/project/uboot/cover/20251119-amd-cleanup-v1-0-c555bd85e6e4@infineon.com/

> Cheers,
> ta
> 
> >
> > 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

Thanks,
Takahiro