Re: [PATCH v2 1/3] regulator: qcom_smd-regulator: fix PM2250 supply parent mappings

[Rakesh Kota]

On Tue, Jul 21, 2026 at 03:31:11PM +0300, Dmitry Baryshkov wrote:
> On Mon, Jul 20, 2026 at 04:25:04PM +0530, Rakesh Kota wrote:
> > The rpm_pm2250_regulators table hardcodes supply parent name strings
> > in the regulator descriptor, causing the Linux regulator framework to
> > look up and vote on parent supplies from APPS. This is both unnecessary
> > and incorrect for RPM-managed regulators.
> > 
> > On RPM-based platforms, the parent-child supply relationships are
> > managed entirely by the RPM firmware. The RPM ensures that parent
> > rails are maintained at the correct voltage with appropriate headroom,
> > based on all active child rail votes across all subsystems. No explicit
> > parent supply vote from APPS is required.
> > 
> > Furthermore, the supply rail connections to PMIC pins are fixed in
> > hardware. The previously hardcoded supply name strings were inaccurate
> > and did not reflect the actual physical pin connections on PM2250-based
> > platforms. The correct supply relationships are to be described in the
> > Device Tree, not hardcoded in the driver.
> 
> Last phrase is incorrect. The driver can hardcode parent supplies (and
> it has been doing it correctly for all other PMICs).

Acknowledged, will rephrase.
> 
> > 
> > To avoid unnecessary APPS-side parent supply access while still
> > allowing correct hardware topology to be described in DT, set the
> > supply name field to NULL in the regulator descriptor.
> 
> Why is this touching only PM2250? Should we drop all parent votes?
>

The fix is conceptually valid for all SMD-managed regulators, but this
series is scoped to PM2250/PM4125 which are the only platforms I have
tested (Agatti, Shikra). Happy to extend it to all entries in a
follow-on series, or do it all at once if preferred — please let me know.

regards
Rakesh kota
> 
> -- 
> With best wishes
> Dmitry