linux-kernel - Re: [PATCH V1 4/4] phy: qcom-qmp-ufs: read max-microamp values from device tree

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: <52625e59-c7d0-45d1-8af3-d9958c5ef01a@quicinc.com>
Date: Fri, 8 Aug 2025 02:15:31 +0530
From: Nitin Rawat <quic_nitirawa@...cinc.com>
To: Mark Brown <broonie@...nel.org>
CC: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, <vkoul@...nel.org>,
        <kishon@...nel.org>, <mani@...nel.org>, <conor+dt@...nel.org>,
        <bvanassche@....org>, <andersson@...nel.org>,
        <neil.armstrong@...aro.org>, <dmitry.baryshkov@....qualcomm.com>,
        <konradybcio@...nel.org>, <krzk+dt@...nel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-phy@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH V1 4/4] phy: qcom-qmp-ufs: read max-microamp values from
 device tree

On 8/8/2025 12:15 AM, Mark Brown wrote:
> On Thu, Aug 07, 2025 at 11:26:17PM +0530, Nitin Rawat wrote:
> 
>> 1. Regulator and PMIC configurations are board-specific, meaning they can
>> vary significantly across different platforms. For example, some boards may
>> use different generations of UFS devices — such as UFS 2.x — which come with
>> distinct power and load requirements and some with UFS3.x which has it own
>> power/load requirement.
> 
> Requirements from generations of UFS devices presumably come from the
> UFS spec and should just be known though?
> 
>> 2. UFS PHY load and PMIC requirements also varies across targets, depending
>> on the underlying technology node and the specific PHY capabilities. These
>> differences can be influenced by the MIPI version or other implementation
>> details.
> 
> If you've got non-enumerable PHYs that have a big impact that's a much
> clearer use case for putting things in DT.

What I meant is that different boards may use different UFS parts, and 
the associated PHY load requirements are not governed by the UFS 
specification itself. Instead, these requirements depend on our specific 
PHY design and MIPI, which can vary across platforms.

Because these characteristics — such as load requirements — are not 
enumerable or automatically detectable, it makes sense to describe them 
explicitly in the device tree. This approach ensures that board-specific 
variations are accurately captured without hardcoding them into the driver.

> 
>> Given this variability, expressing these requirements in the device tree
>> allows for a flexible and accurate way to describe board-specific
>> constraints without hardcoding them into the driver.
> 
> There's still the issue with making this a thing for all regulators, not
> just for this specific device.

I see your point. Just to clarify — my patch is specifically scoped to 
UFS PHY and PLL regulators. The device tree binding defines these 
properties as optional, and they are only enabled for targets where load 
voting is required.

So, this isn’t intended to be a generic change for all regulators, but 
rather a targeted solution for specific consumers that need it.

That’s why I’ve chosen to keep the regulator parsing logic and 
corresponding load voting support within the UFS PHY driver, rather than 
extending it to the core regulator framework.

Thanks,
Nitin