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: <24837866-9da2-9c9d-4094-d604db19cebd@linaro.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ