linux-kernel - Re: [PATCH 1/2] dt-bindings: arm: qcom: Add bindings for IQ8 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] [day] [month] [year] [list]

Message-ID: <3d4a1f7b-dabb-4402-9eac-6f3d93d17ff4@oss.qualcomm.com>
Date: Tue, 15 Jul 2025 18:45:40 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Bjorn Andersson <bjorn.andersson@....qualcomm.com>,
        Umang Chheda <umang.chheda@....qualcomm.com>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel@....qualcomm.com
Subject: Re: [PATCH 1/2] dt-bindings: arm: qcom: Add bindings for IQ8 EVK
 board

On 6/26/25 10:38 AM, Konrad Dybcio wrote:
> 
> 
> On 6/26/25 5:17 AM, Bjorn Andersson wrote:
>> On Mon, Jun 23, 2025 at 06:34:19PM +0530, Umang Chheda wrote:
>>> QCS8275 is another SoC under IQ8 series of SoCs. Unlike QCS8300
>>> which has safety features, it doesn't have safety monitoring feature
>>> of Safety-Island(SAIL) subsystem, which affects thermal management.
>>>
>>
>> QCS8300 and QCS8275 are both the "Monaco" SoC, with some differences in
>> which nodes are "okay" and "disabled", and as you say here some side
>> effects thereof.
>>
>> Describing these as "Monaco" and "Monaco with Sail" would lend itself
>> for a better structure.
>>
>>> qcs8275-iq-8275-evk board is based on QCS8275 SOC.
>>>
>>> Signed-off-by: Umang Chheda <umang.chheda@....qualcomm.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/qcom.yaml | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>> index b14206d11f8b..19823bc91a3b 100644
>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>> @@ -54,6 +54,7 @@ description: |
>>>          msm8998
>>>          qcs404
>>>          qcs615
>>> +        qcs8275
>>
>> Please add "monaco" instead.
>>
>>>          qcs8300
>>>          qcs8550
>>>          qcm2290
>>> @@ -935,6 +936,12 @@ properties:
>>>            - const: qcom,qcs404-evb
>>>            - const: qcom,qcs404
>>>  
>>> +      - items:
>>> +          - enum:
>>> +              - qcom,qcs8275-iq-8275-evk
>>
>> Please use the qcom,monaco- prefix. Is qcom,monaco-evk unique enough?
>> We can sync up offline on this.
>>
>>> +          - const: qcom,qcs8275
>>> +          - const: qcom,qcs8300
>>
>> Please replace these two with just qcom,monaco.
> 
> We could in theory keep the SKU id as a penultimate entry in the top
> level compatible, but I'm not sure it makes sense given what we want
> to achieve (just thinking out loud) - exposing soc_id through
> qcom_socinfo & sysfs seems to be enough, and if it's not, we can
> handle the odd cases separately.
> 
> All in all, let's go with Monaco.

We iterated on this internally and the general agreement is to keep
the numerical name for existing platforms (because drivers or anything
else may be matching against it) and introducing a second label for the
same SoC could spark a situation where a driver checks for qcom,monaco
while older DTs lack it.

We'll go codename-only with future SoC submissions.

tldr:
compatible = "vendor,boardname", "qcom,qcs8300".
filename: codename-boardname.dts

Konrad