Re: [PATCH RESEND v5 0/5] Add FIT multi-DTB selection for Qualcomm

[Sumit Garg <sumit.garg@kernel.org>]

Hi Tom,

On Tue, 13 Oct 2026 at 09:03:07 -0600, Tom Rini wrote:
>On Tue, Oct 13, 2026 at 12:50:42PM +0530, Aswin Murugan wrote:
>>
>> On 10/12/2026 11:20 PM, Tom Rini wrote:
>> Hi Tom,
>> > On Mon, Oct 12, 2026 at 10:37:49PM +0530, Aswin Murugan wrote:
>> > > This series adds dynamic device tree selection from FIT images for
>> > > Qualcomm Snapdragon platforms, enabling U-Boot to select the
>> > > appropriate DTB based on hardware parameters detected at boot.
>> > >
>> > > Qualcomm FIT-based DTB format is documented in [1].
>> > >
>> > > The FIT image contains only DTBs, while the kernel is provided
>> > > separately as part of a UKI image.
>> > >
>> > > The implementation consists of:
>> > >
>> > > 1. Hardware detection infrastructure: Introduces the qcom,hwinfo
>> > >     driver and qcom_hwdetect helper to collect hardware identification
>> > >     data from SMEM, IMEM and TCSR into a single qcom_hw_params
>> > >     structure for consumers such as FIT multi-DTB selection.
>> > >
>> > > 2. FIT multi-DTB selection: Implements DTB selection based on the
>> > >     aggregated hardware information. The code parses metadata DTBs,
>> > >     matches FIT configurations against detected hardware attributes,
>> > >     applies overlays, and loads the selected DTB for EFI boot.
>> > >
>> > > [1] https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/
>> > >      Documentation.md
>> > >
>> > > ---
>> > >
>> > > Changes in v4:
>> > ... which was sent as v5, and this is a re-send of?
>> Yes, this is a resend of v4, which was sent as v5
>> > > 1. Drop the SMEM cache infrastructure.
>> > >
>> > > 2. misc: qcom: add qcom,hwinfo driver to provide a common interface
>> > >     for reading IMEM boot cookie and TCSR SOC version information.
>> > >
>> > > 3. arm: snapdragon: add qcom_hwdetect helper to aggregate hardware
>> > >     information from SMEM, IMEM and TCSR into a single
>> > >     struct qcom_hw_params.
>> > >
>> > > 4. Refactor FIT multi-DTB selection to consume qcom_hw_params instead
>> > >     of accessing SMEM, IMEM and TCSR data directly.
>> > >
>> > > 5. Separate hardware discovery from FIT parsing and DTB matching
>> > >     logic, reducing complexity and improving code organization.
>> > >
>> > > 6. Load FIT images directly from a raw GPT partition and remove the
>> > >     FAT filesystem image based loading approach.
>> > >
>> > > 7. Drop IH_TYPE_FATFS, mkimage FAT image generation support and
>> > >     related documentation updates.
>> > >
>> > > 8. arm: dts: enable qcom,hwinfo on qcs9100-ride-r3, qcs615-ride and
>> > >     qcs6490-rb3gen2 by adding the required qcom,hwinfo DT nodes and
>> > >     board-specific offsets.
>> > >
>> > > Link to v3:
>> > > https://lore.kernel.org/u-boot/20260417120951.3454249-1-aswin.murugan@oss.qualcomm.com/
>> > The FAT comments in v3 were addressed. I'm not really sure the discussion about if
>> > this approach makes sense as really was addressed however?
>>
>> Yes, the FAT-related comments from v3 were addressed in this
>> revision by dropping the FAT filesystem image-based loading
>> approach and loading FIT image directly from a raw GPT
>> partition.
>
>Right, thanks.
>
>> Regarding the broader design, the reasoning for using a
>> DTB-only FIT was discussed in the v3 thread [1]. The intention
>> is to support firmware-side DT selection while keeping DTB
>> management independent of kernel packaging, matching existing
>> Qualcomm deployment models. This is intended to coexist with,
>> rather than replace, approaches such as UKI DT bundling.
>>
>> [1]: https://lore.kernel.org/u-boot/afSXa7q7hJC_ZW07@sumit-xelite/
>
>Yes, and I'd appreciate some of the people that were discussing things
>in that thread chiming in and saying they're happy enough, as it wasn't
>clear to me in re-reading the thread yesterday that the discussion ended
>with agreement and instead just stopped.
>

As of now the Qualcomm subsystem maintenence is in really inactive state
as you can see from the list of patchsets even carrying review tags are
missing custodian attention here [1]. If you remember it from our earlier
private thread with Casey and Neil many months ago, the maintainence
situation hasn't improved at all.

Even as a reviewer for the Qcom subsystem, I have tried earlier with all
the reviews but patches were still floating on the list, which just
demotivated me from doing further reviews.

I would really like to get this maintainence situation fixed. Would it
be fine with you to accept me as a Qcom subsystem custodian with more
people from Qualcomm contributing as reviewers?

In the meantime why we decide on that, can you help with picking patches
which have been reviewed directly for the Qualcomm subsystem?

[1] https://patchwork.ozlabs.org/project/uboot/list/?delegate=151538&param=4&page=1

-Sumit