linux-kernel - Re: [PATCH 14/24] arm64: dts: qcom: Update the pmh0110.dtsi for Glymur

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: <6bf19804-7ce2-4cb6-bdbd-dc12c18330df@oss.qualcomm.com>
Date: Wed, 8 Oct 2025 11:15:54 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
        Pankaj Patil <pankaj.patil@....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>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 14/24] arm64: dts: qcom: Update the pmh0110.dtsi for
 Glymur

On 10/8/25 9:31 AM, Kamal Wadhwa wrote:
> Hi Krzysztof, Dmitry, Konrad,
> 
> On Thu, Sep 25, 2025 at 09:57:02PM +0300, Dmitry Baryshkov wrote:
>> On Thu, Sep 25, 2025 at 10:34:52PM +0900, Krzysztof Kozlowski wrote:
>>> On Thu, 25 Sept 2025 at 22:14, Dmitry Baryshkov
>>> <dmitry.baryshkov@....qualcomm.com> wrote:
>>>>
>>>> On Thu, Sep 25, 2025 at 05:08:54PM +0900, Krzysztof Kozlowski wrote:
>>>>> On Thu, 25 Sept 2025 at 15:34, Pankaj Patil
>>>>> <pankaj.patil@....qualcomm.com> wrote:
>>>>>>
>>>>>> From: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
>>>>>>
>>>>>> Add multiple instance of PMH0110 DT node, one for each assigned
>>>>>> SID for this PMIC on the spmi_bus0 and spmi_bus1 on the Glymur
>>>>>> CRD.
>>>>>>
>>>>>> Take care to avoid compilation issue with the existing nodes by
>>>>>> gaurding each PMH0110 nodes with `#ifdef` for its corresponding
>>>>>> SID macro. So that only the nodes which have the their SID macro
>>>>>> defined are the only ones picked for compilation.
>>>>>>
>>>>>> Signed-off-by: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
>>>>>> Signed-off-by: Pankaj Patil <pankaj.patil@....qualcomm.com>
>>>>>> ---
>>>>>>  arch/arm64/boot/dts/qcom/pmh0110.dtsi | 66 ++++++++++++++++++++++++++++++++++-
>>>>>>  1 file changed, 65 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/qcom/pmh0110.dtsi b/arch/arm64/boot/dts/qcom/pmh0110.dtsi
>>>>>> index b99c33cba8860f1852231db33a127646c08c1e23..4a5c66e5c9fbc35cedb67601f4568844dc41fbea 100644
>>>>>> --- a/arch/arm64/boot/dts/qcom/pmh0110.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/qcom/pmh0110.dtsi
>>>>>> @@ -7,6 +7,8 @@
>>>>>>  #include <dt-bindings/spmi/spmi.h>
>>>>>>
>>>>>>  &spmi_bus0 {
>>>>>> +
>>>>>> +#ifdef PMH0110_D_E0_SID
>>>>>
>>>>> NAK
>>>>>
>>>>> I already explained on IRC in great details why.
>>>>
>>>> A short summary or a link to a channel / date would be nice in order to
>>>> include other people into the discussion.
>>>>
>>>
>>> Of course but:
>>> 1. You were there so maybe you remember the arguments, and:
>>> 2. I'm offline, using phone, not having laptop, replying during my
>>> personal time off just before merge window so any emergency time
>>> should be spent on important matters instead these two huge patch
>>> bombs adding such usage I already said: NO, don't do this.
>>
>>
>> Well, If I'm asking, it means I don't rememebr the discussion. And I
>> defeinitely didn't know that you are spending your personal vacation
>> time in ML. And if the discussion was with some other people, then
>> somebody else can drop the response to the question.
> 
> Just wanted to give some background on this patch.
> Even though PMH0104 and PMH0110 are common (b/w Kaanapali and Glymur),
> they don't share the SIDs. So we tried to use status="disabled" to handle
> this but we observed that because of the node name being common in the
> two included files, it ends up overwriting the previous node with the
> same name.
> 
> eg-
> #include "pmh0104.dtsi"  // assume contains pmic@4 { ...};
> #include "pmh0110.dtsi"  // assume contains pmic@4 { status=disabled;};
> 
> Here intention was to use the pmh0104 on sid-4, but it gets overwritten
> with the pmh0110 on sid-4 ( with status disabled). This is why we ended
> up using the `#ifdef`, ensuring that we can control the exact pmic that
> gets picked by using the PMXXX_SID macro.
> 
> side note, i did `grep` in the `/arch/arm64/boot/dts/` and i see a lot
> of instances of `#if...` present in that.  Assuming the concern here is
> about the use of `#ifdef`.
> 
> Can you suggest some alternative approach?
> or comment on below approaches:-
> 
> 1. Can I use `pmic@...104_d_e0` ?
> This may work but looks like a departure from the current format
> i.e `pmic@<sid>` used in the arch/arm64/boot/dts/qcom.
> 
> 2. Create PMIC-ID based pmic dts? `pmh0104_d_e0.dtsi` and likewise add all
> pmics? But this could mean creating too many pmic files and end up
> bloating the dts/qcom/ directory.
> 
> 3. Add the nodes directly inside glymur-pmics.dtsi ( not using #include)?

This is what we did for x1e after similar conundrums

It adds up to the maintenance cost in theory, but the alternative was worse

Konrad