Re: [regression] of: mis-parsing Depthcharge's /firmware

[Brian Norris <briannorris@chromium.org>]

Hi Rob,

Thanks for your thoughts. I delayed a bit since I wasn't really sure
what the right conclusion was and wanted to give it some thought.

On Tue, Apr 21, 2026 at 02:30:38PM -0500, Rob Herring wrote:
> On Mon, Apr 20, 2026 at 03:54:42PM -0700, Brian Norris wrote:
> > You say it's not novel, but then you say the only existing code is
> > either:
> > 
> > 1) completely different, and only applicable to powerpc or
> > 2) only on your local tree.
> > 
> > That sounds novel to me :)
> > 
> > Anyway, I'm more inclined to lean on my #1 and/or #2 than to write a
> > whole new fixup layer. But maybe #1 can be replaced in the future if we
> > come to really want/need a generic fixup layer in the future.
> 
> The problem with #1 is a) new platforms can then repeat the same mistake 
> and b) we'll forget what platforms needed some work-around and whether 
> we still need to maintain such a work-around. Well, I might not forget, 
> but the next DT maintainer (applications welcome!) even won't know. For 
> example, I have know clue if we still need to carry some of the 
> work-arounds embedded into the interrupt parsing code. That all 
> predates me. The only way I find out is breaking them (I'll never 
> understand why people still run PowerMacs from the 1990s).

Ack to most of this. I'll note that it's possible to write unit tests
for this, if we go for the in-kernel route though, so hopefully that'd
give maintainers a bit more visibility.

> Calling the fixup code a layer is an exageration. It's on my kernel.org 
> tree in the dt/fixup-infrastruct branch. And look, guess what issue it 
> was that it has a fixup for.

OK! I spoke in ignorance then. I really haven't explored the device tree
construction / unflattening logic, so it was new to me.

If it really comes to patching the kernel itself, I'll consider pulling
in your patch. On first glance, it looks good, and not that complex even
to an outsider like me.

> > (Frankly, if we do #2, #1 and #3 will probably both be redundant and
> > unnecessary. I don't know of any case here where we're relying on strict
> > DTB ABI compatibility with no opportunity to update some of the DTS
> > sources.)
> 
> Shrug. I thought the ABI was a concern here. It's ultimately up to the 
> maintainers and users of a given platform whether or not they care about 
> the ABI.

I'm usually on the receiving end of people complaining about ABI. It
seems like we bend over backwards in a lot of places (drivers, driver
frameworks) to maintain some idea of DTB ABI, while in practice, the ABI
is almost never a strict concern for anything I've dealt with -- 98% of
the DTB is generated from in-kernel DTS sources that match the kernel.

($subject case is actually the closest we get to DTB ABI concerns,
because it involves the small part of the DTB that is generated by a
program that is independent from the kernel tree. But even there, it's
possible to fix the issue in the kernel-provided source.)

So it seems to me like maybe it's best to just ignore the ABI concern,
patch the DTS and call it a day. I've done that here:

  https://lore.kernel.org/all/20260428200712.2660635-1-briannorris@chromium.org/
  [PATCH 0/7] dts: Add /firmware/#{address,size}-cells to Chromium-based DTs

If someone finds reason we should still go back to fix the kernel
itself, I can resurrect the fixup logic in addition.

Thanks,
Brian