[GIT PULL] Devicetree updates for v6.13

[GIT PULL] Devicetree updates for v6.13

[Rob Herring]

Linus,

Please pull DT updates for 6.13. There's a few things out of the 
normal spots in arch/ and sound/ which are some updates to callers of DT 
functions.

Rob


The following changes since commit 6e0391e48cf9fb8b1b5e27c0cbbaf2e4639f2c33:

  of: Skip kunit tests when arm64+ACPI doesn't populate root node (2024-10-10 12:43:01 -0500)

are available in the Git repository at:

  ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-for-6.13

for you to fetch changes up to 28b513b5a683cf1e7125ba54ffe7ecb206ef4984:

  Merge branch 'dt/linus' into dt/next (2024-11-15 14:03:59 -0600)

----------------------------------------------------------------
Devicetree updates for v6.13:

Bindings:

- Enable dtc "interrupt_provider" warnings for binding examples.
  Fix the warnings in fsl,mu-msi and ti,sci-inta due to this.

- Convert zii,rave-sp-wdt, zii,rave-sp-pwrbutton,  and
  altr,fpga-passive-serial to DT schema format

- Add some documentation on the different forms of YAML text blocks
  which are a constant source of review comments

- Fix some schema errors in constraints for arrays

- Add compatibles for qcom,sar2130p-pdc and onnn,adt7462

DT core:

- Allow overlay kunit tests to run CONFIG_OF_OVERLAY=n

- Add some warnings on deprecated address handling

- Rework early_init_dt_scan() so the arch can pass in the phys address
  of the DTB as __pa() is not always valid to use. This fixes a warning
  for arm64 with kexec.

- Add and use some new DT graph iterators for iterating over ports and
  endpoints

- Rework reserved-memory handling to be sized dynamically for fixed
  regions

- Optimize of_modalias() to avoid a strlen() call

- Constify struct device_node and property pointers where ever possible

----------------------------------------------------------------
Abel Vesa (1):
      dt-bindings: cache: qcom,llcc: Fix X1E80100 reg entries

Ba Jing (1):
      of:of_numa: remove unused macro

Chanh Nguyen (1):
      dt-bindings: trivial-devices: add onnn,adt7462

Dmitry Baryshkov (1):
      dt-bindings: interrupt-controller: qcom,pdc: Add SAR2130P compatible

Fabio Estevam (1):
      dt-bindings: fpga: altr,fpga-passive-serial: Convert to yaml

Frank Li (2):
      dt-bindings: input: convert zii,rave-sp-pwrbutton.txt to yaml
      dt-bindings: watchdog: convert zii,rave-sp-wdt.txt to yaml format

Kuninori Morimoto (9):
      of: property: add of_graph_get_next_port()
      of: property: add of_graph_get_next_port_endpoint()
      of: property: use new of_graph functions
      ASoC: test-component: use new of_graph functions
      ASoC: audio-graph-card: use new of_graph functions
      ASoC: audio-graph-card2: use new of_graph functions
      gpu: drm: omapdrm: use new of_graph functions
      fbdev: omapfb: use new of_graph functions
      media: xilinx-tpg: use new of_graph functions

Oreoluwa Babatunde (2):
      of: reserved_mem: Restructure how the reserved memory regions are processed
      of: reserved_mem: Add code to dynamically allocate reserved_mem array

Rob Herring (Arm) (16):
      dt-bindings: interrupt-controller: ti,sci-inta: Add missing "#interrupt-cells" to example
      dt-bindings: interrupt-controller: fsl,mu-msi: Drop "interrupt-controller" property
      dt-bindings: Fix array property constraints
      dt-bindings: writing-schema: Add details on YAML text blocks
      logic_pio: Constify fwnode_handle
      PCI: Constify pci_register_io_range() fwnode_handle
      of: Constify struct device_node function arguments
      of: Constify struct property pointers
      of: Constify of_changeset_entry function arguments
      of: Constify safe_name() kobject arg
      of/address: Constify of_busses[] array and pointers
      dt-bindings: Enable dtc "interrupt_provider" warnings
      of/fdt: Don't use default address cell sizes for address translation
      of: WARN on deprecated #address-cells/#size-cells handling
      of/address: Rework bus matching to avoid warnings
      Merge branch 'dt/linus' into dt/next

Sergey Shtylyov (1):
      of: module: remove strlen() call in of_modalias()

Stephen Boyd (1):
      of: Allow overlay kunit tests to run CONFIG_OF_OVERLAY=n

Usama Arif (1):
      of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify

 Documentation/devicetree/bindings/Makefile         |   1 -
 .../devicetree/bindings/cache/l2c2x0.yaml          |   5 +-
 .../devicetree/bindings/cache/qcom,llcc.yaml       |  36 +++-
 .../devicetree/bindings/dma/dma-common.yaml        |   7 +-
 .../devicetree/bindings/example-schema.yaml        |   1 +
 .../bindings/fpga/altera-passive-serial.txt        |  29 ---
 .../bindings/fpga/altr,fpga-passive-serial.yaml    |  74 +++++++
 .../bindings/input/zii,rave-sp-pwrbutton.txt       |  22 --
 .../bindings/input/zii,rave-sp-pwrbutton.yaml      |  36 ++++
 .../bindings/interrupt-controller/arm,gic-v3.yaml  |  12 +-
 .../bindings/interrupt-controller/fsl,mu-msi.yaml  |   4 -
 .../bindings/interrupt-controller/qcom,pdc.yaml    |   1 +
 .../bindings/interrupt-controller/ti,sci-inta.yaml |   1 +
 .../bindings/media/i2c/thine,thp7312.yaml          |   3 +-
 .../bindings/memory-controllers/exynos-srom.yaml   |   5 +-
 .../devicetree/bindings/pci/brcm,stb-pcie.yaml     |   5 +-
 .../devicetree/bindings/soc/qcom/qcom,smp2p.yaml   |   3 +-
 .../devicetree/bindings/trivial-devices.yaml       |   2 +
 .../bindings/watchdog/zii,rave-sp-wdt.txt          |  39 ----
 .../bindings/watchdog/zii,rave-sp-wdt.yaml         |  47 +++++
 .../devicetree/bindings/writing-schema.rst         |  30 +++
 arch/arc/kernel/devtree.c                          |   2 +-
 arch/arm/kernel/devtree.c                          |   2 +-
 arch/arm64/kernel/setup.c                          |   6 +-
 arch/csky/kernel/setup.c                           |   4 +-
 arch/loongarch/kernel/setup.c                      |   2 +-
 arch/microblaze/kernel/prom.c                      |   2 +-
 arch/mips/kernel/prom.c                            |   2 +-
 arch/mips/kernel/relocate.c                        |   2 +-
 arch/nios2/kernel/prom.c                           |   4 +-
 arch/openrisc/kernel/prom.c                        |   2 +-
 arch/powerpc/kernel/dt_cpu_ftrs.c                  |   2 +-
 arch/powerpc/kernel/prom.c                         |   2 +-
 arch/powerpc/platforms/pseries/plpks.c             |   2 +-
 arch/riscv/kernel/setup.c                          |   2 +-
 arch/sh/kernel/setup.c                             |   2 +-
 arch/um/kernel/dtb.c                               |   2 +-
 arch/x86/kernel/devicetree.c                       |   2 +-
 arch/xtensa/kernel/setup.c                         |   2 +-
 drivers/gpu/drm/omapdrm/dss/dpi.c                  |   3 +-
 drivers/gpu/drm/omapdrm/dss/sdi.c                  |   3 +-
 drivers/media/platform/xilinx/xilinx-tpg.c         |  14 +-
 drivers/of/.kunitconfig                            |   1 +
 drivers/of/Kconfig                                 |   2 +-
 drivers/of/address.c                               |  36 ++--
 drivers/of/base.c                                  |  48 +++--
 drivers/of/cpu.c                                   |   2 +-
 drivers/of/dynamic.c                               |   4 +-
 drivers/of/fdt.c                                   |  23 ++-
 drivers/of/fdt_address.c                           |   4 +-
 drivers/of/irq.c                                   |   4 +-
 drivers/of/kexec.c                                 |   2 +-
 drivers/of/kobj.c                                  |   8 +-
 drivers/of/module.c                                |   4 +-
 drivers/of/of_numa.c                               |   3 -
 drivers/of/of_private.h                            |  15 +-
 drivers/of/of_reserved_mem.c                       | 227 ++++++++++++++++-----
 drivers/of/overlay.c                               |  19 +-
 drivers/of/overlay_test.c                          |   2 +
 drivers/of/property.c                              | 109 ++++++++--
 drivers/of/resolver.c                              |  12 +-
 drivers/pci/pci.c                                  |   2 +-
 drivers/video/fbdev/omap2/omapfb/dss/dpi.c         |   3 +-
 drivers/video/fbdev/omap2/omapfb/dss/dss-of.c      |  66 ------
 drivers/video/fbdev/omap2/omapfb/dss/dss.c         |  20 +-
 drivers/video/fbdev/omap2/omapfb/dss/sdi.c         |   3 +-
 include/linux/logic_pio.h                          |   6 +-
 include/linux/of.h                                 |  28 +--
 include/linux/of_address.h                         |   6 +-
 include/linux/of_fdt.h                             |   5 +-
 include/linux/of_graph.h                           |  49 +++++
 include/linux/of_irq.h                             |   4 +-
 include/linux/pci.h                                |   4 +-
 include/video/omapfb_dss.h                         |   8 -
 lib/logic_pio.c                                    |   4 +-
 sound/soc/generic/audio-graph-card.c               |   2 +-
 sound/soc/generic/audio-graph-card2.c              | 104 +++++-----
 sound/soc/generic/test-component.c                 |   3 +-
 78 files changed, 786 insertions(+), 483 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/fpga/altera-passive-serial.txt
 create mode 100644 Documentation/devicetree/bindings/fpga/altr,fpga-passive-serial.yaml
 delete mode 100644 Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt
 create mode 100644 Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.yaml
 delete mode 100644 Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.yaml

Re: [GIT PULL] Devicetree updates for v6.13

[pr-tracker-bot]

The pull request you sent on Mon, 18 Nov 2024 15:07:30 -0600:

> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-for-6.13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e6de688e93a93b98db2ba4929af773038a999e9e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] Devicetree updates for v6.13

[Sasha Levin]

Hi Rob,

On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
>      of: WARN on deprecated #address-cells/#size-cells handling

With the commit above, I've started seeing boot warnings on a few
platforms that KernelCI is testing. One example is:

[    0.047792] ------------[ cut here ]------------
[    0.047803] Missing '#address-cells' in /firmware
[    0.047873] WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x90/0xf0
[    0.047900] Modules linked in:
[    0.047917] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0 #1 933ab9971ff4d5dc58cb378a96f64c7f72e3454d
[    0.047935] Hardware name: Google juniper sku16 board (DT)
[    0.047947] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    0.047961] pc : of_bus_n_addr_cells+0x90/0xf0
[    0.047974] lr : of_bus_n_addr_cells+0x90/0xf0
[    0.047987] sp : ffff80008008ba50
[    0.047997] x29: ffff80008008ba50 x28: ffffcc9644c19060 x27: ffffcc9644b60118
[    0.048016] x26: 0000000000000000 x25: ffff119d7f5c3fe8 x24: ffff80008008bb80
[    0.048034] x23: ffff80008008bb7c x22: ffffcc96441dc0f0 x21: ffffcc9644522170
[    0.048053] x20: ffffcc96454964ed x19: ffff119d7f5c3e28 x18: 0000000000000006
[    0.048071] x17: 64656c62616e655f x16: 0000000000000100 x15: ffff80008008b4d0
[    0.048090] x14: 0000000000000000 x13: 657261776d726966 x12: ffffcc96452d14f0
[    0.048108] x11: 0000000000000001 x10: 0000000000000001 x9 : ffffcc9642742150
[    0.048126] x8 : c0000000ffffdfff x7 : ffffcc9645221450 x6 : 00000000000affa8
[    0.048145] x5 : ffffcc96452d1498 x4 : 0000000000000000 x3 : 0000000000000000
[    0.048163] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff119d40288000
[    0.048182] Call trace:
[    0.048192]  of_bus_n_addr_cells+0x90/0xf0 (P)
[    0.048207]  of_bus_n_addr_cells+0x90/0xf0 (L)
[    0.048222]  of_n_addr_cells+0x24/0x38
[    0.048235]  of_bus_default_count_cells+0x30/0x60
[    0.048251]  __of_get_address+0xb4/0x1c0
[    0.048264]  __of_address_to_resource+0x4c/0x198
[    0.048278]  of_address_to_resource+0x20/0x38
[    0.048292]  of_device_alloc+0x80/0x1a0
[    0.048306]  of_platform_device_create_pdata+0x5c/0x138
[    0.048321]  of_platform_bus_create+0x15c/0x398
[    0.048335]  of_platform_populate+0x58/0x110
[    0.048350]  of_platform_default_populate_init+0x98/0xf8
[    0.048366]  do_one_initcall+0x60/0x320
[    0.048382]  kernel_init_freeable+0x20c/0x420
[    0.048397]  kernel_init+0x28/0x1e8
[    0.048410]  ret_from_fork+0x10/0x20
[    0.048424] ---[ end trace 0000000000000000 ]---
[    0.048445] ------------[ cut here ]------------
[    0.048455] Missing '#size-cells' in /firmware
[    0.048495] WARNING: CPU: 0 PID: 1 at drivers/of/base.c:133 of_bus_n_size_cells+0x90/0xf0
[    0.048513] Modules linked in:
[    0.048526] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W          6.12.0 #1 933ab9971ff4d5dc58cb378a96f64c7f72e3454d
[    0.048544] Tainted: [W]=WARN
[    0.048553] Hardware name: Google juniper sku16 board (DT)
[    0.048563] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    0.048576] pc : of_bus_n_size_cells+0x90/0xf0
[    0.048589] lr : of_bus_n_size_cells+0x90/0xf0
[    0.048602] sp : ffff80008008ba50
[    0.048611] x29: ffff80008008ba50 x28: ffffcc9644c19060 x27: ffffcc9644b60118
[    0.048630] x26: 0000000000000000 x25: ffff119d7f5c3fe8 x24: ffff80008008bb80
[    0.048649] x23: ffff80008008bb7c x22: ffffcc96441dc0f0 x21: ffffcc96445221a8
[    0.048667] x20: ffffcc96454964ed x19: ffff119d7f5c3e28 x18: 0000000000000006
[    0.048686] x17: 64656c62616e655f x16: 0000000000000100 x15: ffff80008008b4d0
[    0.048704] x14: 0000000000000000 x13: 657261776d726966 x12: ffffcc96452d14f0
[    0.048722] x11: 0000000000000001 x10: 0000000000000001 x9 : ffffcc9642742150
[    0.048740] x8 : c0000000ffffdfff x7 : ffffcc9645221450 x6 : 00000000000affa8
[    0.048758] x5 : ffffcc96452d1498 x4 : 0000000000000000 x3 : 0000000000000000
[    0.048776] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff119d40288000
[    0.048794] Call trace:
[    0.048803]  of_bus_n_size_cells+0x90/0xf0 (P)
[    0.048817]  of_bus_n_size_cells+0x90/0xf0 (L)
[    0.048831]  of_n_size_cells+0x24/0x38
[    0.048845]  of_bus_default_count_cells+0x40/0x60
[    0.048859]  __of_get_address+0xb4/0x1c0
[    0.048872]  __of_address_to_resource+0x4c/0x198
[    0.048885]  of_address_to_resource+0x20/0x38
[    0.048899]  of_device_alloc+0x80/0x1a0
[    0.048912]  of_platform_device_create_pdata+0x5c/0x138
[    0.048928]  of_platform_bus_create+0x15c/0x398
[    0.048942]  of_platform_populate+0x58/0x110
[    0.048956]  of_platform_default_populate_init+0x98/0xf8
[    0.048970]  do_one_initcall+0x60/0x320
[    0.048983]  kernel_init_freeable+0x20c/0x420
[    0.048997]  kernel_init+0x28/0x1e8
[    0.049009]  ret_from_fork+0x10/0x20
[    0.049021] ---[ end trace 0000000000000000 ]---


-- 
Thanks,
Sasha

Re: [GIT PULL] Devicetree updates for v6.13

[Krzysztof Kozlowski]

On 24/11/2024 17:29, Sasha Levin wrote:
> Hi Rob,
> 
> On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
>>      of: WARN on deprecated #address-cells/#size-cells handling
> 
> With the commit above, I've started seeing boot warnings on a few

And same boards do not report problems on the next?

> platforms that KernelCI is testing. One example is:
> 
> [    0.047792] ------------[ cut here ]------------
> [    0.047803] Missing '#address-cells' in /firmware
> [    0.047873] WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x90/0xf0
> [    0.047900] Modules linked in:
> [    0.047917] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0 #1 933ab9971ff4d5dc58cb378a96f64c7f72e3454d
> [    0.047935] Hardware name: Google juniper sku16 board (DT)

If this is mt8183-kukui-jacuzzi-juniper-sku16.dts, then it looks like
bootloader adds /firmware node with missing address/size-cells. Is
bootloader updateable there? The dtc reports this as warning for almost
20 years, so I assume the bootloader is just junk or not using dtc.

+Cc Mediatek maintainers as it seems their board.

Best regards,
Krzysztof

Re: [GIT PULL] Devicetree updates for v6.13

[Sasha Levin]

On Sun, Nov 24, 2024 at 05:47:33PM +0100, Krzysztof Kozlowski wrote:
>On 24/11/2024 17:29, Sasha Levin wrote:
>> Hi Rob,
>>
>> On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
>>>      of: WARN on deprecated #address-cells/#size-cells handling
>>
>> With the commit above, I've started seeing boot warnings on a few
>
>And same boards do not report problems on the next?

Looks like they do. I haven't checked it previously, but I see that we
have similar warnings on a few boards that KernelCI is testing -next on.

-- 
Thanks,
Sasha

Re: [GIT PULL] Devicetree updates for v6.13

[AngeloGioacchino Del Regno]

Il 24/11/24 17:59, Sasha Levin ha scritto:
> On Sun, Nov 24, 2024 at 05:47:33PM +0100, Krzysztof Kozlowski wrote:
>> On 24/11/2024 17:29, Sasha Levin wrote:
>>> Hi Rob,
>>>
>>> On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
>>>>      of: WARN on deprecated #address-cells/#size-cells handling
>>>
>>> With the commit above, I've started seeing boot warnings on a few
>>
>> And same boards do not report problems on the next?
> 
> Looks like they do. I haven't checked it previously, but I see that we
> have similar warnings on a few boards that KernelCI is testing -next on.
> 

That's... horrendous.

I hope that we can get a proper fix with a bootloader update on these (now very
old) devices... Adding a Google engineer to the loop so that he can follow up
internally.

The alternative would be to hack-in a firmware node to mt8183-kukui.dtsi, but....
...ugh. That'd be indeed a hack for the sole purpose of fixing a bootloader that
is acting in a broken way, and I don't like that at all (...and I'm sure I'm not
alone!).

Thanks,
Angelo

Re: [GIT PULL] Devicetree updates for v6.13

[Chen-Yu Tsai]

On Mon, Nov 25, 2024 at 5:48 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 24/11/24 17:59, Sasha Levin ha scritto:
> > On Sun, Nov 24, 2024 at 05:47:33PM +0100, Krzysztof Kozlowski wrote:
> >> On 24/11/2024 17:29, Sasha Levin wrote:
> >>> Hi Rob,
> >>>
> >>> On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
> >>>>      of: WARN on deprecated #address-cells/#size-cells handling
> >>>
> >>> With the commit above, I've started seeing boot warnings on a few
> >>
> >> And same boards do not report problems on the next?
> >
> > Looks like they do. I haven't checked it previously, but I see that we
> > have similar warnings on a few boards that KernelCI is testing -next on.
> >
>
> That's... horrendous.
>
> I hope that we can get a proper fix with a bootloader update on these (now very
> old) devices... Adding a Google engineer to the loop so that he can follow up
> internally.

AFAIK that's unlikely going to happen given the resources needed from
the ODMs for a firmware re-qualification. Or we would have fixed the GIC
bug in ATF and had pseudo-NMI.

Some of the firmware code involved is 10 years old, so even the RK3399
Chromebooks, which no longer have support, could suffer from this as
well.

> The alternative would be to hack-in a firmware node to mt8183-kukui.dtsi, but....
> ...ugh. That'd be indeed a hack for the sole purpose of fixing a bootloader that
> is acting in a broken way, and I don't like that at all (...and I'm sure I'm not
> alone!).


Regards
ChenYu

Re: [GIT PULL] Devicetree updates for v6.13

[Krzysztof Kozlowski]

On 25/11/2024 11:34, Chen-Yu Tsai wrote:
> On Mon, Nov 25, 2024 at 5:48 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> Il 24/11/24 17:59, Sasha Levin ha scritto:
>>> On Sun, Nov 24, 2024 at 05:47:33PM +0100, Krzysztof Kozlowski wrote:
>>>> On 24/11/2024 17:29, Sasha Levin wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
>>>>>>      of: WARN on deprecated #address-cells/#size-cells handling
>>>>>
>>>>> With the commit above, I've started seeing boot warnings on a few
>>>>
>>>> And same boards do not report problems on the next?
>>>
>>> Looks like they do. I haven't checked it previously, but I see that we
>>> have similar warnings on a few boards that KernelCI is testing -next on.
>>>
>>
>> That's... horrendous.
>>
>> I hope that we can get a proper fix with a bootloader update on these (now very
>> old) devices... Adding a Google engineer to the loop so that he can follow up
>> internally.
> 
> AFAIK that's unlikely going to happen given the resources needed from
> the ODMs for a firmware re-qualification. Or we would have fixed the GIC
> bug in ATF and had pseudo-NMI.
> 
> Some of the firmware code involved is 10 years old, so even the RK3399
> Chromebooks, which no longer have support, could suffer from this as
> well.
> 
>> The alternative would be to hack-in a firmware node to mt8183-kukui.dtsi, but....
>> ...ugh. That'd be indeed a hack for the sole purpose of fixing a bootloader that
>> is acting in a broken way, and I don't like that at all (...and I'm sure I'm not
>> alone!).
> 

Then we should add it to the exception list. Let me take a look at this.

Best regards,
Krzysztof

Re: [GIT PULL] Devicetree updates for v6.13

[Krzysztof Kozlowski]

On 25/11/2024 12:00, Krzysztof Kozlowski wrote:
> On 25/11/2024 11:34, Chen-Yu Tsai wrote:
>> On Mon, Nov 25, 2024 at 5:48 PM AngeloGioacchino Del Regno
>> <angelogioacchino.delregno@collabora.com> wrote:
>>>
>>> Il 24/11/24 17:59, Sasha Levin ha scritto:
>>>> On Sun, Nov 24, 2024 at 05:47:33PM +0100, Krzysztof Kozlowski wrote:
>>>>> On 24/11/2024 17:29, Sasha Levin wrote:
>>>>>> Hi Rob,
>>>>>>
>>>>>> On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
>>>>>>>      of: WARN on deprecated #address-cells/#size-cells handling
>>>>>>
>>>>>> With the commit above, I've started seeing boot warnings on a few
>>>>>
>>>>> And same boards do not report problems on the next?
>>>>
>>>> Looks like they do. I haven't checked it previously, but I see that we
>>>> have similar warnings on a few boards that KernelCI is testing -next on.
>>>>
>>>
>>> That's... horrendous.
>>>
>>> I hope that we can get a proper fix with a bootloader update on these (now very
>>> old) devices... Adding a Google engineer to the loop so that he can follow up
>>> internally.
>>
>> AFAIK that's unlikely going to happen given the resources needed from
>> the ODMs for a firmware re-qualification. Or we would have fixed the GIC
>> bug in ATF and had pseudo-NMI.
>>
>> Some of the firmware code involved is 10 years old, so even the RK3399
>> Chromebooks, which no longer have support, could suffer from this as
>> well.
>>
>>> The alternative would be to hack-in a firmware node to mt8183-kukui.dtsi, but....
>>> ...ugh. That'd be indeed a hack for the sole purpose of fixing a bootloader that
>>> is acting in a broken way, and I don't like that at all (...and I'm sure I'm not
>>> alone!).
>>
> 
> Then we should add it to the exception list. Let me take a look at this.
https://lore.kernel.org/linux-devicetree/20241125113151.107812-1-krzysztof.kozlowski@linaro.org/T/#u

I sent a fix for this platform only. You did not paste links to other
failing platforms (and sorry but kernelci web interface was absolutely
unmanageable and unusable, so I am not going to even try to look for
them) so not sure who should be added to list of exceptions.


Best regards,
Krzysztof

Re: [GIT PULL] Devicetree updates for v6.13

[AngeloGioacchino Del Regno]

Il 25/11/24 12:33, Krzysztof Kozlowski ha scritto:
> On 25/11/2024 12:00, Krzysztof Kozlowski wrote:
>> On 25/11/2024 11:34, Chen-Yu Tsai wrote:
>>> On Mon, Nov 25, 2024 at 5:48 PM AngeloGioacchino Del Regno
>>> <angelogioacchino.delregno@collabora.com> wrote:
>>>>
>>>> Il 24/11/24 17:59, Sasha Levin ha scritto:
>>>>> On Sun, Nov 24, 2024 at 05:47:33PM +0100, Krzysztof Kozlowski wrote:
>>>>>> On 24/11/2024 17:29, Sasha Levin wrote:
>>>>>>> Hi Rob,
>>>>>>>
>>>>>>> On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
>>>>>>>>       of: WARN on deprecated #address-cells/#size-cells handling
>>>>>>>
>>>>>>> With the commit above, I've started seeing boot warnings on a few
>>>>>>
>>>>>> And same boards do not report problems on the next?
>>>>>
>>>>> Looks like they do. I haven't checked it previously, but I see that we
>>>>> have similar warnings on a few boards that KernelCI is testing -next on.
>>>>>
>>>>
>>>> That's... horrendous.
>>>>
>>>> I hope that we can get a proper fix with a bootloader update on these (now very
>>>> old) devices... Adding a Google engineer to the loop so that he can follow up
>>>> internally.
>>>
>>> AFAIK that's unlikely going to happen given the resources needed from
>>> the ODMs for a firmware re-qualification. Or we would have fixed the GIC
>>> bug in ATF and had pseudo-NMI.
>>>
>>> Some of the firmware code involved is 10 years old, so even the RK3399
>>> Chromebooks, which no longer have support, could suffer from this as
>>> well.
>>>
>>>> The alternative would be to hack-in a firmware node to mt8183-kukui.dtsi, but....
>>>> ...ugh. That'd be indeed a hack for the sole purpose of fixing a bootloader that
>>>> is acting in a broken way, and I don't like that at all (...and I'm sure I'm not
>>>> alone!).
>>>
>>
>> Then we should add it to the exception list. Let me take a look at this.
> https://lore.kernel.org/linux-devicetree/20241125113151.107812-1-krzysztof.kozlowski@linaro.org/T/#u
> 
> I sent a fix for this platform only. You did not paste links to other
> failing platforms (and sorry but kernelci web interface was absolutely
> unmanageable and unusable, so I am not going to even try to look for
> them) so not sure who should be added to list of exceptions.
> 

Are you aware of the new dashboard, or are you referring to the old one?

https://dashboard.kernelci.org/tree

P.S.: If you do have any feedback on how to make it better, please feel free to
give it out: the KCI team will surely be happy to read it.

Cheers,
Angelo

Re: [GIT PULL] Devicetree updates for v6.13

[Sasha Levin]

On Mon, Nov 25, 2024 at 12:33:48PM +0100, Krzysztof Kozlowski wrote:
>On 25/11/2024 12:00, Krzysztof Kozlowski wrote:
>> On 25/11/2024 11:34, Chen-Yu Tsai wrote:
>>> On Mon, Nov 25, 2024 at 5:48 PM AngeloGioacchino Del Regno
>>> <angelogioacchino.delregno@collabora.com> wrote:
>>>>
>>>> Il 24/11/24 17:59, Sasha Levin ha scritto:
>>>>> On Sun, Nov 24, 2024 at 05:47:33PM +0100, Krzysztof Kozlowski wrote:
>>>>>> On 24/11/2024 17:29, Sasha Levin wrote:
>>>>>>> Hi Rob,
>>>>>>>
>>>>>>> On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
>>>>>>>>      of: WARN on deprecated #address-cells/#size-cells handling
>>>>>>>
>>>>>>> With the commit above, I've started seeing boot warnings on a few
>>>>>>
>>>>>> And same boards do not report problems on the next?
>>>>>
>>>>> Looks like they do. I haven't checked it previously, but I see that we
>>>>> have similar warnings on a few boards that KernelCI is testing -next on.
>>>>>
>>>>
>>>> That's... horrendous.
>>>>
>>>> I hope that we can get a proper fix with a bootloader update on these (now very
>>>> old) devices... Adding a Google engineer to the loop so that he can follow up
>>>> internally.
>>>
>>> AFAIK that's unlikely going to happen given the resources needed from
>>> the ODMs for a firmware re-qualification. Or we would have fixed the GIC
>>> bug in ATF and had pseudo-NMI.
>>>
>>> Some of the firmware code involved is 10 years old, so even the RK3399
>>> Chromebooks, which no longer have support, could suffer from this as
>>> well.
>>>
>>>> The alternative would be to hack-in a firmware node to mt8183-kukui.dtsi, but....
>>>> ...ugh. That'd be indeed a hack for the sole purpose of fixing a bootloader that
>>>> is acting in a broken way, and I don't like that at all (...and I'm sure I'm not
>>>> alone!).
>>>
>>
>> Then we should add it to the exception list. Let me take a look at this.
>https://lore.kernel.org/linux-devicetree/20241125113151.107812-1-krzysztof.kozlowski@linaro.org/T/#u
>
>I sent a fix for this platform only. You did not paste links to other
>failing platforms (and sorry but kernelci web interface was absolutely
>unmanageable and unusable, so I am not going to even try to look for
>them) so not sure who should be added to list of exceptions.

The new dashboard isn't *that* bad :)

A list of platforms that show this issue:

- google,spherion-rev3 | google,spherion-rev2
- google,steelix-sku131072 | google,steelix
- google,tomato-rev2 | google,tomato | mediatek,mt8195
- google,juniper-sku16 | google,juniper | mediatek,mt8183
- google,kingoftown | qcom,sc7180
- google,lazor-rev5-sku5 | google,lazor-rev5-sku6

-- 
Thanks,
Sasha

Re: [GIT PULL] Devicetree updates for v6.13

[Rob Herring]

On Mon, Nov 25, 2024 at 7:24 AM Sasha Levin <sashal@kernel.org> wrote:
>
> On Mon, Nov 25, 2024 at 12:33:48PM +0100, Krzysztof Kozlowski wrote:
> >On 25/11/2024 12:00, Krzysztof Kozlowski wrote:
> >> On 25/11/2024 11:34, Chen-Yu Tsai wrote:
> >>> On Mon, Nov 25, 2024 at 5:48 PM AngeloGioacchino Del Regno
> >>> <angelogioacchino.delregno@collabora.com> wrote:
> >>>>
> >>>> Il 24/11/24 17:59, Sasha Levin ha scritto:
> >>>>> On Sun, Nov 24, 2024 at 05:47:33PM +0100, Krzysztof Kozlowski wrote:
> >>>>>> On 24/11/2024 17:29, Sasha Levin wrote:
> >>>>>>> Hi Rob,
> >>>>>>>
> >>>>>>> On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
> >>>>>>>>      of: WARN on deprecated #address-cells/#size-cells handling
> >>>>>>>
> >>>>>>> With the commit above, I've started seeing boot warnings on a few
> >>>>>>
> >>>>>> And same boards do not report problems on the next?
> >>>>>
> >>>>> Looks like they do. I haven't checked it previously, but I see that we
> >>>>> have similar warnings on a few boards that KernelCI is testing -next on.
> >>>>>
> >>>>
> >>>> That's... horrendous.
> >>>>
> >>>> I hope that we can get a proper fix with a bootloader update on these (now very
> >>>> old) devices... Adding a Google engineer to the loop so that he can follow up
> >>>> internally.
> >>>
> >>> AFAIK that's unlikely going to happen given the resources needed from
> >>> the ODMs for a firmware re-qualification. Or we would have fixed the GIC
> >>> bug in ATF and had pseudo-NMI.
> >>>
> >>> Some of the firmware code involved is 10 years old, so even the RK3399
> >>> Chromebooks, which no longer have support, could suffer from this as
> >>> well.
> >>>
> >>>> The alternative would be to hack-in a firmware node to mt8183-kukui.dtsi, but....
> >>>> ...ugh. That'd be indeed a hack for the sole purpose of fixing a bootloader that
> >>>> is acting in a broken way, and I don't like that at all (...and I'm sure I'm not
> >>>> alone!).
> >>>
> >>
> >> Then we should add it to the exception list. Let me take a look at this.
> >https://lore.kernel.org/linux-devicetree/20241125113151.107812-1-krzysztof.kozlowski@linaro.org/T/#u
> >
> >I sent a fix for this platform only. You did not paste links to other
> >failing platforms (and sorry but kernelci web interface was absolutely
> >unmanageable and unusable, so I am not going to even try to look for
> >them) so not sure who should be added to list of exceptions.
>
> The new dashboard isn't *that* bad :)

You are reporting this issue because it is that bad. I tested this on
KCI before this even went to next. I gave up trying to get boot logs
out from all the boards. Though which boards run seems to be a crap
shoot, but that's not a dashboard problem.

>
> A list of platforms that show this issue:
>
> - google,spherion-rev3 | google,spherion-rev2
> - google,steelix-sku131072 | google,steelix
> - google,tomato-rev2 | google,tomato | mediatek,mt8195
> - google,juniper-sku16 | google,juniper | mediatek,mt8183
> - google,kingoftown | qcom,sc7180
> - google,lazor-rev5-sku5 | google,lazor-rev5-sku6

Can I get a dump of the DTB for one of these boards? The upstream dts
files don't seem to have a /firmware node.

Rob

Re: [GIT PULL] Devicetree updates for v6.13

[Chen-Yu Tsai]

[-- Attachment #1: Type: text/plain, Size: 4146 bytes --]

On Mon, Nov 25, 2024 at 09:15:56AM -0600, Rob Herring wrote:
> On Mon, Nov 25, 2024 at 7:24 AM Sasha Levin <sashal@kernel.org> wrote:
> >
> > On Mon, Nov 25, 2024 at 12:33:48PM +0100, Krzysztof Kozlowski wrote:
> > >On 25/11/2024 12:00, Krzysztof Kozlowski wrote:
> > >> On 25/11/2024 11:34, Chen-Yu Tsai wrote:
> > >>> On Mon, Nov 25, 2024 at 5:48 PM AngeloGioacchino Del Regno
> > >>> <angelogioacchino.delregno@collabora.com> wrote:
> > >>>>
> > >>>> Il 24/11/24 17:59, Sasha Levin ha scritto:
> > >>>>> On Sun, Nov 24, 2024 at 05:47:33PM +0100, Krzysztof Kozlowski wrote:
> > >>>>>> On 24/11/2024 17:29, Sasha Levin wrote:
> > >>>>>>> Hi Rob,
> > >>>>>>>
> > >>>>>>> On Mon, Nov 18, 2024 at 03:07:30PM -0600, Rob Herring wrote:
> > >>>>>>>>      of: WARN on deprecated #address-cells/#size-cells handling
> > >>>>>>>
> > >>>>>>> With the commit above, I've started seeing boot warnings on a few
> > >>>>>>
> > >>>>>> And same boards do not report problems on the next?
> > >>>>>
> > >>>>> Looks like they do. I haven't checked it previously, but I see that we
> > >>>>> have similar warnings on a few boards that KernelCI is testing -next on.
> > >>>>>
> > >>>>
> > >>>> That's... horrendous.
> > >>>>
> > >>>> I hope that we can get a proper fix with a bootloader update on these (now very
> > >>>> old) devices... Adding a Google engineer to the loop so that he can follow up
> > >>>> internally.
> > >>>
> > >>> AFAIK that's unlikely going to happen given the resources needed from
> > >>> the ODMs for a firmware re-qualification. Or we would have fixed the GIC
> > >>> bug in ATF and had pseudo-NMI.
> > >>>
> > >>> Some of the firmware code involved is 10 years old, so even the RK3399
> > >>> Chromebooks, which no longer have support, could suffer from this as
> > >>> well.
> > >>>
> > >>>> The alternative would be to hack-in a firmware node to mt8183-kukui.dtsi, but....
> > >>>> ...ugh. That'd be indeed a hack for the sole purpose of fixing a bootloader that
> > >>>> is acting in a broken way, and I don't like that at all (...and I'm sure I'm not
> > >>>> alone!).
> > >>>
> > >>
> > >> Then we should add it to the exception list. Let me take a look at this.
> > >https://lore.kernel.org/linux-devicetree/20241125113151.107812-1-krzysztof.kozlowski@linaro.org/T/#u
> > >
> > >I sent a fix for this platform only. You did not paste links to other
> > >failing platforms (and sorry but kernelci web interface was absolutely
> > >unmanageable and unusable, so I am not going to even try to look for
> > >them) so not sure who should be added to list of exceptions.
> >
> > The new dashboard isn't *that* bad :)
> 
> You are reporting this issue because it is that bad. I tested this on
> KCI before this even went to next. I gave up trying to get boot logs
> out from all the boards. Though which boards run seems to be a crap
> shoot, but that's not a dashboard problem.
> 
> >
> > A list of platforms that show this issue:
> >
> > - google,spherion-rev3 | google,spherion-rev2
> > - google,steelix-sku131072 | google,steelix
> > - google,tomato-rev2 | google,tomato | mediatek,mt8195
> > - google,juniper-sku16 | google,juniper | mediatek,mt8183
> > - google,kingoftown | qcom,sc7180
> > - google,lazor-rev5-sku5 | google,lazor-rev5-sku6
> 
> Can I get a dump of the DTB for one of these boards? The upstream dts
> files don't seem to have a /firmware node.

Attached two files. These were copied from /sys/firmware/fdt.

- juniper.dtb - google,juniper-sku16 | google,juniper | mediatek,mt8183
- steelix.dtb - google,steelix-sku131072 | google,steelix | mediatek,mt8186

juniper.dtb is the upstream dts plus some changes I need to get the
external display to work, plus whatever the *existing* firmware inserts.

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

[-- Attachment #2: juniper.dtb --]
[-- Type: application/octet-stream, Size: 88207 bytes --]

[-- Attachment #3: steelix.dtb --]
[-- Type: application/octet-stream, Size: 98078 bytes --]

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

[Brian Norris]

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

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

So far, this does the trick, but I didn't review all the ramifications
here.

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 4034d798c55a..f86386c407d4 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -328,7 +328,15 @@ static int of_bus_default_flags_match(struct device_node *np)
 
 static int of_bus_default_match(struct device_node *np)
 {
-	return of_property_present(np, "#address-cells");
+	int len;
+
+	if (of_property_present(np, "#address-cells"))
+		return true;
+
+	if (of_find_property(np, "ranges", &len) && len == 0)
+		return true;
+
+	return false;
 }
 
 /*

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

[Rob Herring]

On Fri, Apr 17, 2026 at 4:26 PM Brian Norris <briannorris@chromium.org> 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