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: <c1435858-6288-4525-8c92-e27ed86cb55e@sirena.org.uk>
Date: Thu, 7 Aug 2025 18:43:46 +0100
From: Mark Brown <broonie@...nel.org>
To: Nitin Rawat <quic_nitirawa@...cinc.com>
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 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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)