linux-kernel - Re: [PATCH 1/3] dt-bindings: power: rpmpd: Add Generic RPM(h) PD indexes

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, 6 Jul 2023 20:17:00 +0530
From:   Rohit Agarwal <quic_rohiagar@...cinc.com>
To:     Pavan Kondeti <quic_pkondeti@...cinc.com>
CC:     <agross@...nel.org>, <andersson@...nel.org>,
        <konrad.dybcio@...aro.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] dt-bindings: power: rpmpd: Add Generic RPM(h) PD
 indexes


On 7/6/2023 8:00 PM, Pavan Kondeti wrote:
> On Thu, Jul 06, 2023 at 06:19:51PM +0530, Rohit Agarwal wrote:
>> Add Generic RPM(h) Power Domain indexes that can be used
>> for all the Qualcomm SoC henceforth.
>>
>> Signed-off-by: Rohit Agarwal <quic_rohiagar@...cinc.com>
>> Suggested-by: Konrad Dybcio <konrad.dybcio@...aro.org>
> Does it make sense to give this link [1] so that we know what is
> Konrad's suggestion and the discussion around it?
>
> [1]
> https://lore.kernel.org/all/0d468d08-6410-e424-b4f3-5245cdb0334a@linaro.org/
Yes, could be given in the cover letter.
>> ---
>>   include/dt-bindings/power/qcom-rpmpd.h | 49 ++++++++++++++++++++++++++++++++++
>>   1 file changed, 49 insertions(+)
>>
>> diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
>> index 83be996..6498251 100644
>> --- a/include/dt-bindings/power/qcom-rpmpd.h
>> +++ b/include/dt-bindings/power/qcom-rpmpd.h
>> @@ -4,6 +4,55 @@
>>   #ifndef _DT_BINDINGS_POWER_QCOM_RPMPD_H
>>   #define _DT_BINDINGS_POWER_QCOM_RPMPD_H
>>   
>> +/* Generic RPMH Power Domain Indexes */
>> +#define RPMHPD_CX		0
>> +#define RPMHPD_MX		1
>> +#define RPMHPD_CX_AO		2
>> +#define RPMHPD_MX_AO		3
>> +#define RPMHPD_GFX		4
>> +#define RPMHPD_MSS		5
>> +#define RPMHPD_EBI		6
>> +#define RPMHPD_LCX		7
>> +#define RPMHPD_LMX		8
>> +#define RPMHPD_MMCX		9
>> +#define RPMHPD_MMCX_AO		10
>> +#define RPMHPD_MXC		11
>> +#define RPMHPD_MXC_AO		12
>> +#define RPMHPD_NSP		13
>> +#define RPMHPD_NSP0		14
>> +#define RPMHPD_NSP1		15
>> +#define RPMHPD_QPHY		16
>> +#define RPMHPD_DDR		17
>> +#define RPMHPD_XO		18
>> +
>> +/* Generic RPM Power Domain Indexes */
>> +#define RPMPD_VDDCX		0
>> +#define RPMPD_VDDCX_AO		1
>> +#define RPMPD_VDDMX		2
>> +#define RPMPD_VDDMX_AO		3
>> +#define RPMPD_VDDCX_VFL		4
>> +#define RPMPD_VDDMX_VFL		5
>> +#define RPMPD_VDDCX_VFC		6
>> +#define RPMPD_LPI_CX		7
>> +#define RPMPD_LPI_MX		8
>> +#define RPMPD_SSCCX		9
>> +#define RPMPD_SSCCX_VFL		10
>> +#define RPMPD_SSCMX		11
>> +#define RPMPD_SSCMX_VFL		12
>> +#define RPMPD_VDDSSCX		13
>> +#define RPMPD_VDDSSCX_VFC	14
>> +#define RPMPD_VDDGFX		15
>> +#define RPMPD_VDDGFX_VFC	16
>> +#define RPMPD_VDDGX		17
>> +#define RPMPD_VDDGX_AO		18
>> +#define RPMPD_VDDMDCX		19
>> +#define RPMPD_VDDMDCX_AO	20
>> +#define RPMPD_VDDMDCX_VFC	21
>> +#define RPMPD_VDDMD		22
>> +#define RPMPD_VDDMD_AO		23
>> +#define RPMPD_LPICX_VFL		24
>> +#define RPMPD_LPIMX_VFL		25
>> +
> How did you come up with this list? A union of all SoCs supported by
> RPMh driver?
Yes, union of all the SoCs and arranged based on frequencies of usage.

Thanks,
Rohit.
>>   /* SA8775P Power Domain Indexes */
>>   #define SA8775P_CX	0
>>   #define SA8775P_CX_AO	1
>> -- 
>> 2.7.4
>>
> Thanks,
> Pavan