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:

quoted

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.

quoted

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

quoted

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