Re: [PATCH v2 3/3] arm64: dts: qcom: Fix pm4125 vbus regulator compatible and constraints

[Rakesh Kota]

On Thu, Jul 02, 2026 at 02:07:12PM +0200, Konrad Dybcio wrote:
> On 7/2/26 9:33 AM, Rakesh Kota wrote:
> > On Wed, Jul 01, 2026 at 01:26:11PM +0200, Konrad Dybcio wrote:
> >> On 7/1/26 12:28 PM, Rakesh Kota wrote:
> >>> Remove pm8150b fallback compatible from pm4125_vbus and fix regulator
> >>> constraints in qrb2210 DTS files to use microvolt instead of
> >>> microamp.
> >>>
> >>> Signed-off-by: Rakesh Kota <rakesh.kota@xxxxxxxxxxxxxxxx>
> >>> ---
> >>>  arch/arm64/boot/dts/qcom/pm4125.dtsi               | 2 +-
> >>>  arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 4 ++--
> >>>  arch/arm64/boot/dts/qcom/qrb2210-rb1.dts           | 4 ++--
> >>>  3 files changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/pm4125.dtsi b/arch/arm64/boot/dts/qcom/pm4125.dtsi
> >>> index 542e8fe030da40dfefc7b744dcc30133fdb35e74..3dc8d667d091ceb4267081d32b7aae983fc25071 100644
> >>> --- a/arch/arm64/boot/dts/qcom/pm4125.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/pm4125.dtsi
> >>> @@ -37,7 +37,7 @@ pm4125_resin: resin {
> >>>  		};
> >>>  
> >>>  		pm4125_vbus: usb-vbus-regulator@1100 {
> >>> -			compatible = "qcom,pm4125-vbus-reg", "qcom,pm8150b-vbus-reg";
> >>> +			compatible = "qcom,pm4125-vbus-reg";
> >>>  			reg = <0x1100>;
> >>>  			status = "disabled";
> >>>  		};
> >>> diff --git a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
> >>> index bf088fa9807f040f0c8f405f9111b01790b09377..2b50f3f577577d30a87fcb6466c7d7690270aaa3 100644
> >>> --- a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
> >>> +++ b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
> >>> @@ -235,8 +235,8 @@ &mdss_dsi0_phy {
> >>>  };
> >>>  
> >>>  &pm4125_vbus {
> >>> -	regulator-min-microamp = <500000>;
> >>> -	regulator-max-microamp = <500000>;
> >>> +	regulator-min-microvolt = <4250000>;
> >>> +	regulator-max-microvolt = <5000000>;
> >>
> >> Perhaps that's a stupid question, but is there any good reason to
> >> not just keep it at 5V if enabled?
> >>
> > We could hardcode 5V, but keeping the range allows clients to select a
> > lower voltage if needed. The driver supports voltage selection per use
> > case, so hardcoding 5V would restrict that flexibility.
> 
> I'm trying to understand if this would ever happen in practice
>
Fair point.The dependent client here is the one connecting the USB
device to the Host. We don't have a concrete example today, but the
voltage range is kept flexible to avoid restricting future use cases.
That said, if 5V is the agreed practical default, we're open to
hardcoding it for simplicity.

regards
Rakesh Kota