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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <aee74e0f-c957-437d-ab48-3977013c3116@kernel.org>
Date: Fri, 25 Jul 2025 10:25:27 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Yijie Yang <yijie.yang@....qualcomm.com>,
 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 25/07/2025 10:03, Yijie Yang wrote:
> 
> 
> 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'?

Yes. We already discussed this with qcom last time for other soc/som.
Just look how all other vendors do it.

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

There is no SoC name here. The SoC name stays the same and you do not
change it just because your internal policy changes every X years.

> 
>>
>>>
>>> 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?

No. Drop all references to Hamoa because it is irrelevant. You do not
get to change existing bindings or existing meanings just because you
decided to use some other model names.

Best regards,
Krzysztof