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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <31461227-3f3a-4316-9c8a-c851209d0278@quicinc.com>
Date: Thu, 7 Aug 2025 23:26:17 +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/7/2025 11:13 PM, Mark Brown wrote:
> On Thu, Aug 07, 2025 at 11:05:08PM +0530, Nitin Rawat wrote:
>> On 8/7/2025 10:56 PM, Mark Brown wrote:
> 
>>> The issue isn't using regulator_set_load(), that's perfectly fine and
>>> expected.  The issue is either reading the value to use from the
>>> constraint information (which is just buggy) or adding a generic
>>> property for this (which I'm not convinced is a good idea, I'd expect a
>>> large propoprtion of drivers should just know what their requirements
>>> are and that a generic property would just get abused).
> 
>>>> These drivers also define corresponding binding properties, as seen in the
>>>> UFS instances documented here:
> 
>>>> UFS Common DT Binding ((link - https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/ufs/ufs-common.yaml?h=next-20250807)
> 
>>> Note that that's specifying OPPs which is different...
> 
>> Sorry for the confusion .Instead, I meant the following three properties
>> defined in the link to ufs-common.yaml binding, which specify the maximum
>> load that can be drawn from the respective power supplies.
> 
>>    vcc-max-microamp:
>>      description:
>>        Specifies max. load that can be drawn from VCC supply.
>>
>>    vccq-max-microamp:
>>      description:
>>        Specifies max. load that can be drawn from VCCQ supply.
>>
>>    vccq2-max-microamp:
>>      description:
>>        Specifies max. load that can be drawn from VCCQ2 supply.
> 
> OK, but that's still not motivating putting things in DT (the properties
> are there but don't explain why) and having this for some devices
> doesn't really address the why make it a generic rather than device
> specific part of things like Konrad was suggesting.  Perhaps there's
> enough board specific variation that it does make sense to put something
> specific to this consumer in DT, but it'd be another step to make it a
> generic thing that applies to all regulators.

Hi Mark,

Thanks for your review and feedback.
To address your question about why these properties should be included 
in the device tree:

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.

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.

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.

Thanks,
Nitin