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

[Rob Herring <robh@kernel.org>]

On Mon, Apr 20, 2026 at 03:54:42PM -0700, Brian Norris wrote:
> On Mon, Apr 20, 2026 at 05:19:06PM -0500, Rob Herring wrote:
> > On Mon, Apr 20, 2026 at 3:57 PM Brian Norris <briannorris@chromium.org> wrote:
> > > On Mon, Apr 20, 2026 at 07:57:40AM -0500, Rob Herring wrote:
> > > > On Fri, Apr 17, 2026 at 4:26 PM Brian Norris <briannorris@chromium.org> wrote:
> > > > > Can we patch of_bus_default_match() to accept an empty 'ranges' [1]? Or
> > > > > should I go patch every Chromium-device DTS file I can find? So far, I
> > > > > think I can get that done in 17 files in the upstream tree...
> > > >
> > > > Both.
> > >
> > > To be clear, my options were:
> > >
> > > 1. fix up kernel parsing to accept these /firmware/coreboot node
> > >    structures (with empty ranges / no #{address,size}-cells)
> > > 2. add #{address,size}-cells into the kernel-included dts(i) files (this
> > >    will merge safely with the DTB modifications patched in by old
> > >    bootloaders).
> > >
> > > I wouldn't call #2 "kernel fixup the DT", personally. I'd call it "fix
> > > up the DT source that happens to be provided by the kernel." This
> > > assumes no one is using device trees that are exclusively maintained
> > > outside the kernel. (I believe that's generally true, except for
> > > OpenWrt. And even there, it's still acceptable to patch the DT source,
> > > and I've already done so.)
> > >
> > > > Though I'd rather the kernel fixup the DT rather than relax the
> > > > parsing code for everyone. Then we know what platforms need this and
> > > > don't let new ones in.
> > >
> > > I'm not sure how to parse this. This paragraph sounds like a 3rd option:
> > 
> > Well, not in the sense of pick one of 3 options. It's another option
> > in how to fix the kernel.
> 
> Ah, got it. So it's an alternative to #1.
> 
> > I think we should fix any .dts files we can
> > in addition to fixing the kernel.
> 
> OK. I have patches for both, and I'll see about sending them out in the
> next day or two.
> 
> > > 3. "kernel fixup the DT" -- sound like you want the kernel to identify
> > >    these specific /firmware/coreboot structures, and activtly
> > >    modify/patch the FDT at runtime
> > >
> > > Is that an accurate interpretation? If so, that sounds rather novel, and
> > > nothing like "both" (#1 + #2 above). It's certainly possible, but seems
> > > like a large lift for this particular incompatibility.
> > 
> > Yes. It's not novel though. The powerpc code is littered with such
> > things. Some of them due to the commit in question here. Look at
> > commits from me in arch/powerpc.
> > 
> > I started some common infrastructure to apply fixups, but the case in
> > particular that needed it ended up not needing it. So it's something I
> > have on a branch somewhere. Also it worked on the unflattened tree as
> > not all things need to be fixed up early.
> 
> 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).

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.

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

Rob