linux-kernel - Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

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: <e42b7bdd-e9a1-47d9-9d97-c4da9e3a553a@quicinc.com>
Date: Fri, 22 Aug 2025 14:54:52 +0530
From: Nitin Rawat <quic_nitirawa@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
CC: <vkoul@...nel.org>, <kishon@...nel.org>, <mani@...nel.org>,
        <andersson@...nel.org>, <konradybcio@...nel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-phy@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650
 and SM8750



On 8/22/2025 2:49 PM, Dmitry Baryshkov wrote:
> On 21/08/2025 19:02, Nitin Rawat wrote:
>>
>>
>> On 8/20/2025 5:24 PM, Dmitry Baryshkov wrote:
>>> On Wed, Aug 20, 2025 at 12:07:57PM +0530, Nitin Rawat wrote:
>>>>
>>>>
>>>> On 8/20/2025 6:19 AM, Dmitry Baryshkov wrote:
>>>>> On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
>>>>>> Add regulator load voting support for SM8650 and SM8750 platforms by
>>>>>> introducing dedicated regulator bulk data arrays with their load
>>>>>> values.
>>>>>>
>>>>>> The load requirements are:
>>>>>> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
>>>>>> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
>>>>>>
>>>>>> This ensures stable operation and proper power management for these
>>>>>> platforms where regulators are shared between the QMP USB PHY and
>>>>>> other IP blocks by setting appropriate regulator load currents 
>>>>>> during PHY
>>>>>> operations.
>>>>>>
>>>>>> Configurations without specific load requirements will continue to 
>>>>>> work
>>>>>> unchanged, as init_load_uA remains zero-initialized 
>>>>>> when .init_load_uA
>>>>>> is not provided.
>>>>>
>>>>> Can we please get configuration for the rest of the platforms?
>>>>
>>>> Hi Dmitry,
>>>>
>>>> If you're okay with it, can I merge the configuration for the remaining
>>>> platforms in the next patch series after I complete testing on all 
>>>> remaining
>>>> platforms.
>>>
>>> You don't need to test, finding MSM8996 or 98 might be troublesome. Just
>>> fill in the values from the hardware documentation.
>>
>> Hi Dmitry,
>>
>> While implementing changes for all remaining platform, I noticed that 
>> the "regulator-allow-set-load" property is defined only for SM8750 and 
>> SM8850 within the PMIC PHY and PLL device tree nodes which means that 
>> even if the UFS PHY driver is updated to vote for this configuration 
>> on other platforms, it will have no impact.
> 
> If I remember correctly, on other platforms we don't allow setting the 
> load exactly because consumers were not voting on the current/power 
> requirements.
> 
>>
>> Should I still proceed with applying the change across all platform, 
>> or limit it to just the SM8750 and SM8850 drivers? What’s your 
>> recommendation?
> 
> I think, we should proceed, then once all PHYs get those votes we can 
> enable load toggling on those platforms too.

Sure Dmitry. I'll make the change in next patchset.



> 
>>
>> ===========================================================================
>> // Device tree:
>> vreg_l1j_0p91: ldo1 {
>>      regulator-name = "vreg_l1j_0p91";
>>      regulator-min-microvolt = <880000>;
>>      regulator-max-microvolt = <920000>;
>>      regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>>      regulator-allow-set-load;
>>      regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM 
>> RPMH_REGULATOR_MODE_HPM>;
>> };
>>
>> ===========================================================================
>> drivers/regulator/of_regulator.c
>>
>>
>> if (of_property_read_bool(np, "regulator-allow-set-load"))
>>          constraints->valid_ops_mask |= REGULATOR_CHANGE_DRMS;
>>
>> ===========================================================================
>> //drivers/regulator/core.c
>> static int drms_uA_update(struct regulator_dev *rdev)
>> {
>>      ...
>>      if (!regulator_ops_is_valid(rdev, REGULATOR_CHANGE_DRMS)) {
>>          rdev_dbg(rdev, "DRMS operation not allowed\n");
>>          return 0;
>>      }
>>      ...
>> }
>>
>>
>> Regards,
>> Nitin
>>
>>
>>
>>
>>>
>>
> 
>