linux-kernel - Re: [PATCH v2 1/7] arm64: dts: qcom: sm8450: add spmi node

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]

Date:   Thu, 29 Dec 2022 12:31:30 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        linux-arm-msm@...r.kernel.org, andersson@...nel.org,
        agross@...nel.org
Cc:     marijn.suijten@...ainline.org, Vinod Koul <vkoul@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/7] arm64: dts: qcom: sm8450: add spmi node

On 29/12/2022 12:04, Konrad Dybcio wrote:
> 
> 
> On 29.12.2022 11:57, Krzysztof Kozlowski wrote:
>> On 29/12/2022 11:45, Konrad Dybcio wrote:
>>>
>>>
>>> On 29.12.2022 11:42, Krzysztof Kozlowski wrote:
>>>> On 29/12/2022 11:32, Konrad Dybcio wrote:
>>>>> From: Vinod Koul <vkoul@...nel.org>
>>>>>
>>>>> Add the spmi bus as found in the SM8450 SoC
>>>>>
>>>>> Signed-off-by: Vinod Koul <vkoul@...nel.org>
>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@...ainline.org>
>>>>> [Konrad: 0x0 -> 0, move #cells down, make reg-names a vertical list]
>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>>>>> ---
>>>>> v1 -> v2:
>>>>> No changes
>>>>>
>>>>>  arch/arm64/boot/dts/qcom/sm8450.dtsi | 22 ++++++++++++++++++++++
>>>>>  1 file changed, 22 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>>> index 570475040d95..b9b59c5223eb 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>>> @@ -2715,6 +2715,28 @@ aoss_qmp: power-controller@...0000 {
>>>>>  			#clock-cells = <0>;
>>>>>  		};
>>>>>  
>>>>> +		spmi_bus: spmi@...d000 {
>>>>
>>>> Hmm looks different than reg.
>>>>
>>>>> +			compatible = "qcom,spmi-pmic-arb";
>>>>> +			reg = <0 0x0c400000 0 0x00003000>,
>>>>> +			      <0 0x0c500000 0 0x00400000>,
>>>>> +			      <0 0x0c440000 0 0x00080000>,
>>>>> +			      <0 0x0c4c0000 0 0x00010000>,
>>>>> +			      <0 0x0c42d000 0 0x00010000>;
>>>> x
>>> Hm, my guess would be that Vinod chose to put the "cnfg" reg
>>> instead of "core" in the unit address, as 8450 has 2 SPMI bus
>>> hosts and they both share the core reg, so it would have been
>>> impossible to have two spmi@...e nodes..
>>
>> Eh? SM8450 has 2 SPMI hosts both using 0x0c400000? How does that work?
>> Usually address can be mapped only once.
> No idea either!
> 
>>
>> Where is the second SPMI? I cannot find it in linux-next.
> It's only there on downstream and I'm not sure how useful it is
> really, only some debug subdevice is attached to it.. Perhaps
> we could ignore its existence for now and I could use the core
> reg in unit address for spmi0?

I see it indeed in downstream. core, chnls and obsrvr IO are the same.
There is quite of debug devices attached.

There is a comment in PMIC arbiter code to use a IO mapping allowing
simultaneous mappings, so this is actually valid.

Anyway, DT expects unit address to match first reg, so if we want to
have second PMIC, we need to change the order of reg entries.

We can ignore this problem till we add second PMIC...

Best regards,
Krzysztof