[RFH] SPI and SPI-NOR patch help

[RFH] SPI and SPI-NOR patch help

[Tom Rini]

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

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.

-- 
Tom

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

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

[Conor Dooley]

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

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.

Cheers,
Conor.

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

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

[Michael Walle]

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

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

-michael

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

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

[Tom Rini]

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

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

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

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

[Miquel Raynal]

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.

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.

> 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

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

[Peter Robinson]

On Wed, 18 Feb 2026 at 13:40, Miquel Raynal <miquel.raynal@bootlin.com> 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.
>
> 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

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

[Miquel Raynal]

On 18/02/2026 at 14:20:56 GMT, Peter Robinson <pbrobinson@gmail.com> wrote:

> On Wed, 18 Feb 2026 at 13:40, Miquel Raynal <miquel.raynal@bootlin.com> 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.
>>
>> 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.

Sounds like a legitimate use case. I was actually referring to Software
Block Protection bits (BP, TB, INV).

Thanks,
Miquèl

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

[Tudor Ambarus]

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.

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

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

[Tom Rini]

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

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.

-- 
Tom

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

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

[Tudor Ambarus]

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.

Cheers,
ta

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

[Tom Rini]

[-- 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 --]

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

[Takahiro.Kuwano]

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

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

[Tudor Ambarus]

On 2/24/26 10:39 AM, Takahiro.Kuwano@infineon.com wrote:
>> 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.
> 

Wonderful!

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

+1

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

[Tom Rini]

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

On Tue, Feb 24, 2026 at 12:23:33PM +0200, Tudor Ambarus wrote:
> 
> 
> On 2/24/26 10:39 AM, Takahiro.Kuwano@infineon.com wrote:
> >> 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.
> > 
> 
> Wonderful!

I too am very glad to hear this. Can you please send a patch to update
the MAINTAINER file? Thanks again!

-- 
Tom

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