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

[Brian Norris <briannorris@chromium.org>]

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.

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

Brian