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

[Rob Herring]

On Fri, Apr 17, 2026 at 4:26 PM Brian Norris <briannorris@xxxxxxxxxxxx> wrote:
>
> Hi all,
>
> (New subject; was "Re: [GIT PULL] Devicetree updates for v6.13")
>
> On Mon, Dec 09, 2024 at 05:28:09PM +0800, Chen-Yu Tsai wrote:
> > steelix.dtb is the same, plus the firmware now inserts #address-cells
> > and #size-cells under /firmware. This fix has landed for all future
> > ChromeOS devices via our main firmware branch [1].
> >
> > AFAIK they also have a bad FDT END symbol. This was only recently
> > discovered and fixed for future devices [2].
> >
> >
> > ChenYu
> >
> > [1] Gerrit: https://crrev.com/c/6051580
> > [2] Gerrit: https://review.coreboot.org/c/coreboot/+/85462
>
> This all comes back to bite us, since nobody went back to patch the
> existing Chromebook device trees, and now we've added a true regression
> on top:
>
> In commit 6e5773d52f4a ("of/address: Fix WARN when attempting
> translating non-translatable addresses") we now reject devices without
> '#address-cells', and this breaks the DTs generated by bootloaders
> without Chen-Yu's https://crrev.com/c/6051580 fix (this is ... pretty
> much all Chromebooks). Specifically, Linux now refuses to add 'reg'
> resources to the /firmware/coreboot device, and we fail with:
>
> [   11.886271] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
>
> This is almost certainly a DTB ABI regression.
>
> This was noticed here (OpenWrt supports some Chromium-based WiFi routers
> that use Depthcharge-based bootloaders from many years ago):
>
> https://github.com/openwrt/openwrt/issues/21243
>
> For now, I just patched up the OpenWrt DTS files like so:
> https://github.com/openwrt/openwrt/pull/22951
>
> But what should we do going forward? I note that Rob says "We may
> revisit this later and address with a fixup to the DT itself" in commit
> 8600058ba28a ("of: Add coreboot firmware to excluded default cells
> list").
>
> That never happened, and a ton of Chromium devices are still broken.

The above just silenced the warning. If they are broken, then
something else broke them.

> (They don't have WARNINGs, but /sys/firmware/vpd, etc., is still
> missing.)
>
> 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.

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.

>
> Brian
>
> [1] From ePAPR:
>
>   "If the [ranges] property is defined with an <empty> value, it
>   specifies that the parent and child address 28 space is identical, and
>   no address translation is required."
>
> And:
>
>   "An ePAPR-compliant boot program shall supply #address-cells and
>   #size-cells on all nodes 16 that have children.
>
>   If missing, a client program should assume a default value of 2 for
>   #address-cells, and a value of 1 for #size-cells."

ePAPR may say that, but that's not what the kernel implements,
defaulting to 1 address cell (on !SPARC). dtc however does default to
2 cells. Relying on defaults has been a warning in dtc essentially
forever. I'd like to get rid of defaults in the kernel

Rob