linux-kernel - Re: [PATCH] regulator: qcom_smd: Keep one rpm handle for all vregs

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: <8ef0364b-2649-4bef-81bf-30934afb1e38@linaro.org>
Date: Wed, 3 Jan 2024 11:03:49 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
 Bjorn Andersson <andersson@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
 Mark Brown <broonie@...nel.org>
Cc: Marijn Suijten <marijn.suijten@...ainline.org>,
 linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: qcom_smd: Keep one rpm handle for all vregs

On 27.12.2023 12:48, Dmitry Baryshkov wrote:
> On 27/12/2023 03:29, Konrad Dybcio wrote:
>> For no apparent reason (as there's just one RPM per SoC), all vregs
>> currently store a copy of a pointer to smd_rpm. Introduce a single,
>> global one to save up on space in each definition.
>>
>> bloat-o-meter reports:
>>
>> Total: Before=43944, After=43924, chg -0.05%
>>
>> plus sizeof(ptr) on every dynamically allocated regulator :)
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>> ---

[...]

>>   @@ -1440,11 +1438,10 @@ static int rpm_reg_probe(struct platform_device *pdev)
>>       const struct rpm_regulator_data *vreg_data;
>>       struct device_node *node;
>>       struct qcom_rpm_reg *vreg;
>> -    struct qcom_smd_rpm *rpm;
>>       int ret;
>>   -    rpm = dev_get_drvdata(pdev->dev.parent);
>> -    if (!rpm) {
>> +    smd_vreg_rpm = dev_get_drvdata(pdev->dev.parent);
>> +    if (!smd_vreg_rpm) {
> 
> I thought about having a mutex around (I don't remember if secondary PMICs and/or chargers can be routed through RPM or not).

A mutex for assigning this?

Konrad
> 
> Then I went on checking other RPM and SMD-RPM drivers.
> 
> clk-rpm: global variable, field
> clk-smd-rpm: struct field
> regulator_qcom-smd-rpm: struct field
> 
> Probably it's worth using the same approach in all four drivers?