[qcom-next] Add OF_LIVE device tree fixup infrastructure

[aswinm94]

This PR introduces a comprehensive OF_LIVE device tree fixup
infrastructure for Qualcomm Snapdragon platforms. The implementation
provides runtime device tree modifications to pass platform-specific
information from SMEM to the operating system through device tree.

Qualcomm Snapdragon SoCs require runtime device tree modifications to
provide accurate platform information that cannot be statically defined
in device tree source files. This includes:

Board-specific identification and variant information
DDR memory configuration
Hardware subset parts
SoC-specific device node adjustments

upstream-link: https://lore.kernel.org/all/20260113115404.1448759-1-aswin.murugan@oss.qualcomm.com/#t

This PR drops the Add cached SMEM socinfo accessor api patch & SMEM cache infra from the series, these were added as part of FIT DTB Change

[b49020]

This patch-set has got quite negative feedback upstream. I agree with that feedback since it's not clear at all how upstream kernel is going to consume following info without corresponding DT bindings or drivers:

Board-specific identification and variant information
DDR memory configuration
Hardware subset parts
SoC-specific device node adjustments

First get the corresponding DT consumers upstream in the kernel before proceeding here.

[WilliamBright-IMD]

Isn't this just applying to the Linux DT since its just patching the kernel DTS within ft_board_setup based off the blown fuses?
Isn't something also needed to fix-up the u-boot DTS too because it needs to also know about the memory size and fused off parts of the chip?

Its probably unlikely to use them as u-boot tends to not support the full DTS but its probably worth doing and I expect the memory size fixup is highly important too

[aswinm94]

Isn't this just applying to the Linux DT since its just patching the kernel DTS within ft_board_setup based off the blown fuses? Isn't something also needed to fix-up the u-boot DTS too because it needs to also know about the memory size and fused off parts of the chip?

Its probably unlikely to use them as u-boot tends to not support the full DTS but its probably worth doing and I expect the memory size fixup is highly important too

Isn't this just applying to the Linux DT since its just patching the kernel DTS within ft_board_setup based off the blown fuses? Isn't something also needed to fix-up the u-boot DTS too because it needs to also know about the memory size and fused off parts of the chip?

Its probably unlikely to use them as u-boot tends to not support the full DTS but its probably worth doing and I expect the memory size fixup is highly important too

yes, there is also activity going on to dynamically configure memory nodes of uboot dts

[WilliamBright-IMD]

Isn't this just applying to the Linux DT since its just patching the kernel DTS within ft_board_setup based off the blown fuses? Isn't something also needed to fix-up the u-boot DTS too because it needs to also know about the memory size and fused off parts of the chip?
Its probably unlikely to use them as u-boot tends to not support the full DTS but its probably worth doing and I expect the memory size fixup is highly important too

Isn't this just applying to the Linux DT since its just patching the kernel DTS within ft_board_setup based off the blown fuses? Isn't something also needed to fix-up the u-boot DTS too because it needs to also know about the memory size and fused off parts of the chip?
Its probably unlikely to use them as u-boot tends to not support the full DTS but its probably worth doing and I expect the memory size fixup is highly important too

yes, there is also activity going on to dynamically configure memory nodes of uboot dts

Great, we are using the qcs8550 (6 core variant) and for now we are using u-boot as a UEFI app with DTB fix ups before booting into Linux.
Please let me know if you have any patches that you want testing that enable bare-metal (EL1) u-boot support for the 8550 and I can them a go

[aswinm94]

The DDR memory fixup is very critical and is required to be populated by bootloader
the usable physical memory layout cannot be fully described in the kernel DTS, as it depends
on firmware carve‑outs and platform configuration determined at
runtime.
Hence the memory fixup is moved to separate PR
#53
and other fixups are part of this PR for trackability

[b49020]

@WilliamBright-IMD

Isn't something also needed to fix-up the u-boot DTS too because it needs to also know about the memory size and fused off parts of the chip?

The memory fixups are already being done by U-Boot DT overrides like this one here: https://github.com/qualcomm-linux/u-boot/blob/qcom-next/arch/arm/dts/qcs6490-rb3gen2-u-boot.dtsi. These are automatically updated for kernel via EFI memory map.

What we really need is the SMEM APIs that can avoid those DT memory overrides in U-Boot. Something this series tries to address: https://patchwork.ozlabs.org/project/uboot/list/?series=433987&state=*. The status although shows incorrectly as accepted.

[b49020]

What we really need is the SMEM APIs that can avoid those DT memory overrides in U-Boot. Something this series tries to address: https://patchwork.ozlabs.org/project/uboot/list/?series=433987&state=*. The status although shows incorrectly as accepted.

#56 from Casey should provide the relevant implementation required.