linux-kernel - Re: [PATCH v2 1/4] dt-bindings: arm: qcom: Document HAMOA-IOT-EVK board

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3803aed8-3b32-4a7b-860f-8fe049f5ddee@oss.qualcomm.com>
Date: Fri, 25 Jul 2025 16:03:06 +0800
From: Yijie Yang <yijie.yang@....qualcomm.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] dt-bindings: arm: qcom: Document HAMOA-IOT-EVK
 board



On 2025-07-25 14:55, Krzysztof Kozlowski wrote:
> On 24/07/2025 10:15, Yijie Yang wrote:
>> Document the device tree binding for a new board named "EVK" based on
>> the Qualcomm Hamoa-IoT platform.
> 
> What is hamoa-iot?
> 
> Later patches claim this is a SoM, so explain here why you are not
> expecting it to be used outside of EVK (not following standard SoM rules
> like every other vendor)?

The SoM can be used outside of the EVK. Regarding the standard SoM rules 
you mentioned—are you referring to the expectation that a SoM should 
have its own compatible string, such as 'qcom,hamoa-iot-som'?

> 
>>
>> The "hamoa" name refers to a family of SoCs that share the same silicon
>> die but are offered in multiple speed bins. The specific SoC used in
>> this board is the x1e80100, which represents one such bin within the
>> Hamoa family.
> 
> Isn't this obvious from the schema?

This is the first patch set where the Hamoa code name is introduced, so 
I’d like to clarify the relationship between the Hamoa family and the 
SoC ID. Additionally, I want to explain why the compatible string 
includes both the board’s code name and the SoC name.

> 
>>
>> Although "qcom,hamoa-iot-evk" is introduced as the board-specific
>> compatible, the fallback compatible remains "qcom,x1e80100" to preserve
>> compatibility with existing in-kernel drivers and software that already
>> depend on this identifier.
> 
> Not relevant. This is x1e80100 SoC. We do not explain that
> microsoft,romulus15 is using fallback x1e80100, do we?

Same as above.

> 
> You explain less relevant topics but you do not explain the main
> concerns here. It does not matter how you name your board. Can be hamoa,
> can be lemans - we don't care about board names.
> 

I will add more details to describe the relationship between the board 
and the SoM. This is what people are most concerned about, right?

>>
>> Signed-off-by: Yijie Yang <yijie.yang@....qualcomm.com>
>> ---
>>   Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>> index 47a7b1cb3cac1150bcde8c2e2e23f2db256ab082..f004019c5691e0a9a3d56a0e3af395314ceb3745 100644
>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>> @@ -1161,6 +1161,7 @@ properties:
>>                 - lenovo,yoga-slim7x
>>                 - microsoft,romulus13
>>                 - microsoft,romulus15
>> +              - qcom,hamoa-iot-evk
>>                 - qcom,x1e80100-crd
>>                 - qcom,x1e80100-qcp
>>             - const: qcom,x1e80100
>>
> 
> 
> Best regards,
> Krzysztof

-- 
Best Regards,
Yijie