Re: [PATCH v11 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Yijie Yang <yijie.yang@oss.qualcomm.com>]

On 2025-09-15 17:53, Stephan Gerhold wrote:
> yOn Mon, Sep 15, 2025 at 05:46:09PM +0800, Yijie Yang wrote:
>>
>>
>> On 2025-09-15 16:52, Stephan Gerhold wrote:
>>> On Mon, Sep 15, 2025 at 10:12:15AM +0800, Yijie Yang wrote:
>>>>
>>>>
>>>> On 2025-09-12 16:48, Stephan Gerhold wrote:
>>>>> On Wed, Sep 10, 2025 at 05:02:11PM +0800, Yijie Yang wrote:
>>>>>> The HAMOA-IOT-SOM is a compact computing module that integrates a System
>>>>>> on Chip (SoC) — specifically the x1e80100 — along with essential
>>>>>> components optimized for IoT applications. It is designed to be mounted on
>>>>>> carrier boards, enabling the development of complete embedded systems.
>>>>>>
>>>>>> Make the following peripherals on the SOM enabled:
>>>>>> - Regulators on the SOM
>>>>>> - Reserved memory regions
>>>>>> - PCIe6a and its PHY
>>>>>> - PCIe4 and its PHY
>>>>>> - USB0 through USB6 and their PHYs
>>>>>> - ADSP, CDSP
>>>>>> - Graphic
>>>>>> - Video
>>>>>>
>>>>>> Written in collaboration with Yingying Tang (PCIe4)
>>>>>> <quic_yintang@quicinc.com> and Wangao Wang (Video)
>>>>>> <quic_wangaow@quicinc.com>.
>>>>>
>>>>> This looks like you should have Co-developed-by: tags together with
>>>>> their Signed-off-by: tags.
>>>>
>>>> We’ve agreed on this as the preferred method for marking collaboration, as
>>>> discussed earlier in this thread.
>>>>
>>>
>>> I can't say I agree with Bjorn there, but ok, he's the maintainer. :-)
>>>
>>>>>
>>>>>>
>>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>> ---
>>>>>>     arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 621 ++++++++++++++++++++++++++++
>>>>>>     1 file changed, 621 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
>>>>>> new file mode 100644
>>>>>> index 000000000000..c7c3a167eb6a
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
>>>>>> @@ -0,0 +1,621 @@
>>>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>>>> +/*
>>>>>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>>>>>> + */
>>>>>> +
>>>>>> +#include "x1e80100.dtsi"
>>>>>> +#include "x1e80100-pmics.dtsi"
>>>>>> +#include <dt-bindings/gpio/gpio.h>
>>>>>> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
>>>>>> +
>>>>>> +/ {
>>>>>> +	compatible = "hamoa-iot-som", "qcom,x1e80100";
>>>>>
>>>>> Undocumented compatible (without "qcom," prefix). I think you can just
>>>>> drop this?
>>>>
>>>> This compatible string was also discussed previously and is the preferred
>>>> choice. I’ll add the missing 'qcom,' prefix.
>>>>
>>>
>>> Even compatible = "qcom,hamoa-iot-som", "qcom,x1e80100"; is not
>>> documented. And it doesn't make much sense to document it either, each
>>> of the boards using the SoM should have a more specific compatible and
>>> therefore needs to override this property. I think you can really just
>>> drop this line.
>>
>> Patch 1/4 documents this compatible. It’s another requirement that SoC/SoM
>> should follow, which Krzysztof pointed out in v2:
>> https://lore.kernel.org/all/aee74e0f-c957-437d-ab48-3977013c3116@kernel.org/
>>
> 
> I'm not saying you should drop the "qcom,hamoa-iot-som" compatible. My
> point is that only the compatible list you use in hamoa-iot-evk.dts is
> documented in PATCH 1/4:
> 
> compatible = "qcom,hamoa-iot-evk", "qcom,hamoa-iot-som", "qcom,x1e80100";
> 
> The compatible list you are using in hamoa-iot-som.dtsi is *not*
> documented:
> 
> compatible = "(qcom,)hamoa-iot-som", "qcom,x1e80100";
> 
> because the board-specific compatible string (e.g. "qcom,hamoa-iot-evk")
> is missing.
> 
> The compatible property you have in hamoa-iot-som.dtsi is redundant,
> because you override it with the valid one in hamoa-iot-evk.dts. And
> every other board using the SoM should do the same.
> 
> I would expect that you can just drop this line in hamoa-iot-som.dtsi.

Yes, the compatible property in this context will ultimately be 
overridden by the board file and does not have any direct functional impact.

However, DTS/DTSI files are intended to describe the hardware itself, 
and this compatible string helps characterize the SOM—even if it is 
later overridden. This is similar to the role of compatible strings in 
certain soc.dtsi files.

Therefore, I believe it is appropriate to retain this compatible and 
provide documentation to clarify its purpose.

A useful reference for this approach is the imx8mp-sr-som.dtsi file from 
another vendor.

> 
> Thanks,
> Stephan

-- 
Best Regards,
Yijie