[PATCH net 2/2] net/stmmac: Verify provided DTS AXI setup

[Jakub Raczynski]

On Tue, Jul 07, 2026 at 09:04:00PM +0200, Andrew Lunn wrote:
> On Tue, Jul 07, 2026 at 07:44:31PM +0200, Jakub Raczynski wrote:
> > During parsing of AXI setup, there are few issues:
> > - 'axi_blen' array is uninitialized value on stack without zero-init stack
> >   configured. This can result in random AXI burst length config if
> >   DTS config provides shorter array than AXI_BLEN.
> 
> What does the DT blinding say about the length? Is it allowed to be
> short?
> 
> Are we talking about:
> 
>       snps,blen:
>         $ref: /schemas/types.yaml#/definitions/uint32-array
>         description:
>           this is a vector of supported burst length.
>         minItems: 7
>         maxItems: 7
> 
> So it should be 7. Are there any in kernel DT blobs which don't pass
> 7? Can we just error out when it is not 7?

Erroring would be fine, as wrong amount will pass.
Same as previous answer, I start to agree more and more that code should give
more errors rather silent fix stuff.
This is mostly Sashiko complaining but I have seen this being incorrect in
some internal forks.
But, as a code is currently written, this does not have to be 7 and
documentation is merely a suggestions. I doubt wrong DTS would pass to
mainline linux so it is merely 'internal' fix.

> 
> > - In case of failed memory allocation for AXI and error, there is no handling
> >   of that. Fix it by checking if AXI config is error and return if so,
> >   as this can only lack of memory. No AXI config, although is probably
> >   wrong in most cases, is not treated as error, as generic config is mostly
> >   provided in drivers.
> 
> This seems like a different fix. Maybe put it into a patch of its own.
> 

Got that.

> > Fixes: afea03656add ("stmmac: rework DMA bus setting and introduce new platform AXI structure")
> 
> Again, does this bother anybody? At least axi_blen issue seems to be
> that the DT blob is broken, so i doubt it actually does. Are there
> reports of memory allocation error and resulting Opps.
> 

Only internal and quickly fixed. No public reports.

BR
Jakub Raczynski