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