Re: [PATCH v3 0/2] regulator: qcom-rpmh: Add off-on-delay support

[Kamal Wadhwa]

On Tue, Sep 08, 2026 at 02:26:23PM +0100, Mark Brown wrote:
> On Tue, Sep 08, 2026 at 06:43:09PM +0530, Kamal Wadhwa wrote:
> > On Mon, Jun 29, 2026 at 02:13:00PM +0200, Konrad Dybcio wrote:
> 
> > > In that case, I see no real downside in allowing that, especially given
> > > it would/should be used sparingly and only in cases like you mentioned
> > > where the board has some quirks
> 
> > yes. we can use this sparingly for such board issues.
> 
> > @Mark, @Rob - can you please comment if you think this is acceptable?
> 
> Could you please ask a specific question?  What is "this" here?  There
> is an large amount of quoted material in the message and referencs to
> some property but I'm not clear which one.

I'm sorry.
let me elaborate.

Saikiran had posted this patch series which introduced a "regulator-off-on-delay-us"
property to qcom-rpmh-regulator.c for "Lenovo Yoga Slim 7x (Snapdragon X Elite)".
But after discussions with you and Rob, he decided to use an alternative approach
and not pursue this patch
https://lore.kernel.org/all/20260127190211.14312-1-bjsaikiran@xxxxxxxxx/

However recently on Qualcomm's QCS8300 RB4 boards we started seeing "NOP OUT" issue
for UFS driver, where this patch seems to be helping.

The issue was seen only when a quick Off->On operation happened due to defer and
re-probe of the UFS driver (note - defer was due to some other reasons unrelated
to regulator), combined with the extra caps on the boards, as UFS and EMMC (which
needed more caps) shared same rails led to this situation.

While analyzing the issue it was found that adding a delay between the regulator
Off->On operation helps the UFS work properly, allowing more time for the rail to
go down.

Since the boards are already in production and the HW design cannot be changed,
we'd like your opinion on whether this patch can be taken in its current form.

Also, Rob had earlier raised a few points to Saikiran on this patch series
(https://lore.kernel.org/all/20260129174829.GA1324020-robh@xxxxxxxxxx/):

1. About calling "regulator-off-on-delay-us" a "standard" property (which is not correct)
2. If this property will force the off-on-delay on all the regulators under the pmic
3. If we can avoid turning the regulator off itself, so we may not need this delay

point 1 - I can fix in the v2, by correcting the commit message.

point 2 - As I confirmed to Konrad above, the property is per-regulator, so other
regulators under the same driver will not be impacted.

point 3 - We evaluated this for UFS - but the problem is that the issue happens in
the defer probe path, so if we avoid turning off the regulator, it leads to long
error prints appearing for the regulator being left ON. So we couldn't take that
path.

You may also refer to this
https://lore.kernel.org/all/20260515111647.qg75thdvcbvvjpoi@xxxxxxxxxxxxxxxxxxxxxxxxxx/
for a more detailed flow of the issue from the UFS perspective.

> 
> Please also do not add random extra characters to my name, and also
> you've CCed konrad.dybcio@xxxxxxxxxx which appears invalid.

sorry for this, it seems by mistake i added `.` there.