Re: [PATCH V1 2/4] arm64: dts: qcom: sm8750: add max-microamp for UFS PHY and PLL supplies

[Krzysztof Kozlowski <krzk@kernel.org>]

On 08/08/2025 10:58, Konrad Dybcio wrote:
> On 8/8/25 9:29 AM, Krzysztof Kozlowski wrote:
>> On Wed, Aug 06, 2025 at 09:13:38PM +0530, Nitin Rawat wrote:
>>> Add `vdda-phy-max-microamp` and `vdda-pll-max-microamp` properties to
>>> the UFS PHY node in the device tree.
>>>
>>> These properties define the maximum current (in microamps) expected
>>> from the PHY and PLL regulators. This allows the PHY driver to
>>> configure regulator load accurately and ensure proper regulator
>>> mode based on load requirements.
>>
>> That's not the property of phy, but regulator.
>>
>> Also reasoning is here incomplete - you just post downstream code. :/
> 
> The reason for this change is good, but perhaps not explained clearly
> 
> All of these values refer to the maximum current draw that needs to be
> allocated on a shared voltage supply for this peripheral (because the


It sounds very different than how much it can be drawn. How much can be
drawn is the property of the regulator. The regulator knows how much
current it can support.


> supply's capabilities change depending on the maximum potential load
> at any given time, which the regulator driver must be aware of)
> 
> This is a property of a regulator *consumer*, i.e. if we had a chain
> of LEDs hanging off of this supply, we'd need to specify NUM_LEDS * 
> MAX_CURR under the "led chain" device, to make sure that if the
> aggregated current requirements go over a certain threshold (which is
> unknown to Linux and hidden in RPMh fw), the regulator can be
> reconfigured to allow for a higher current draw (likely at some
> downgrade to efficiency)


The problem is that rationale is downstream. Instead I want to see some
reason: e.g. datasheets, spec, type of UFS device (that was the argument
in the driver patch discussion).

The only argument here for given value is: downstream has it.

Best regards,
Krzysztof