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

[Nitin Rawat]

On 8/12/2025 1:18 AM, Nitin Rawat wrote:
> On 8/11/2025 9:20 PM, Bjorn Andersson wrote:
> > On Thu, Aug 07, 2025 at 08:09:56PM +0100, Mark Brown wrote:
> > > On Thu, Aug 07, 2025 at 07:43:15PM +0200, Konrad Dybcio wrote:
> > > > On 8/7/25 7:26 PM, Mark Brown wrote:
> > >
> > > > > Note that that's specifying OPPs which is different...
> > >
> > > > The microamp properties are in the top-level, not under OPP if
> > > > that's what you meant
> > >
> > > I mean the OPPs use case is an existing well known one for dumping stuff
> > > into DT.
> > >
> > > > > That doesn't mean that it's a good idea to put that information in the
> > > > > DT, nor if it is sensible to put in DT does it mean that it's a good
> > > > > idea to define a generic property that applies to all regulator
> > > > > consumers which is what I now think Konrad is proposing.
> > >
> > > > Yeah, that's what I had in mind
> > >
> > > > I was never able to get a reliable source for those numbers myselfe
> > > > either.. At least some of them are prooooobably? chosen based on the
> > > > used regulator type, to ensure it's always in HPM..
> > >
> > > That's what set_mode() is for.  Like I say it's becoming less and less
> > > relevant though.
> >
> > set_mode() just applies the mode to the regulator_dev, so in cases where
> > you have multiple consumers of a regulator_dev things would break.
> >
> > Further, there are numerous cases where we have multiple consumers each
> > needing a "low" mode, but their combined load requires a "high" mode.
> >
> > set_load() and its aggregation of the inputs deals with both of these
> > issues.
> >
> >
> > Whether mode setting is becoming less relevant in our hardware, that I
> > don't have the definitive answer to.
> >
> > > > That said, our drivers cover a wide variety of hardware, built on a
> > > > wide variety of process nodes, with different configurations, etc.,
> > > > so it's either polluting the DT, or polluting the driver with
> > > > per-compatible hardcoded data (and additional compatibles because
> > > > fallbacks wouldn't work most of the time)
> >
> > If this is our reason for putting it in DeviceTree, then we should write
> > that in the commit message :)
> >
> > > That's really not a persuasive argument for adding a genric property
> > > that applies to all regulator consumers...
> >
> > I agree, even if we determine that this belongs in DT, because it needs
> > to be tweaked on a per-board basis, it's still only applicable to a
> > fraction of our device nodes.
>
> Hi Bjorn & Mark,
>
> I had a follow-up discussion with the PHY designer to confirm whether 
> this value could vary at the board level. Based on their response, it's 
> a fixed value for the SoC and remains consistent across different 
> boards. Therefore, I'm comfortable removing it from the device tree and 
> using hardcoded, per-compatible data in the driver.
>
> The only concern is that this approach may lead to driver bloat over 
> time, as more SoCs are added and each requires its own hardcoded 
> configuration.
>
> Regards,
> Nitin
Based on the current understanding, I plan to post a revised patch that 
uses hardcoded, per-compatible data within the driver, rather than 
specifying it in the device tree. Please let me know if anyone has any 
concerns with this approach.

Thanks,
Nitin


> > Regards,
> > Bjorn
> >
> > > My instinct with this stuff is generally to avoid putting it in the DT,
> > > we see far too many instances where someone's typed some numbers in
> > > wrongly or discovers the ability to drive the hardware harder and needs
> > > to tune the numbers - once something is ABI you're stuck just trusting
> > > the numbers.  That said I'm not going to stop you putting something
> > > specific to this driver in there, I just don't think this is a good idea
> > > as a generic property.