RE: [PATCH v2 2/3] arm64: dts: exynos: ExynosAutov920: Add regulators for the USB

[<pritam.sutar@samsung.com>]

Hi Krzysztof,

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, February 19, 2026 1:24 AM
> To: pritam.sutar@samsung.com; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; alim.akhtar@samsung.com
> Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org;
> rosa.pila@samsung.com; dev.tailor@samsung.com;
> faraz.ata@samsung.com; muhammed.ali@samsung.com;
> selvarasu.g@samsung.com
> Subject: Re: [PATCH v2 2/3] arm64: dts: exynos: ExynosAutov920: Add
> regulators for the USB
> 
> On 18/02/2026 10:28, pritam.sutar@samsung.com wrote:
> >>>>> +	usbdrd31_dwc3_vbus: usbdrd31_dwc3-vbus {
> >>>>
> >>>> Please use name for all fixed regulators which matches current
> >>>> format
> >>>> recommendation: 'regulator-[0-9]v[0-9]'
> >>>>
> >>>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.
> >>>> gi
> >>>> t/tree/
> >>>> Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
> >>>>
> >>>> None of the regulators are called like you wrote. Really NONE.
> >>>>
> >>>
> >>> Thank you for the references. Will bring changes for regulator's
> >>> name and labels as
> >>>
> >>> -       usbdrd31_dwc3_vbus: usbdrd31_dwc3-vbus {
> >>> +       reg_usbdrd31_dwc3_vbus: regulator-1 {
> >>
> >> Did you read the binding? That's not what I asked.
> >>
> >
> > Yes.
> > Sorry for misinterpreting above comment. Is it expected as below?
> >
> > This is based on our understanding by referring binding and other vendor
> dts.
> >
> > --- a/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
> > +++ b/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
> > @@ -59,7 +59,7 @@ dummy_regulator: regulator-0 {
> >                  regulator-name = "dummy_regulator";
> >         };
> >
> > -       usbdrd31_dwc3_vbus: usbdrd31_dwc3-vbus {
> > +       reg_usb_vbus0: regulator-5v0-vbus0 {
> 
> Yes, that's better.

Thank you for the confirmation.

> 
> Only under the assumption these are actually dedicated single-enable-pin
> regulators, not pins going to the PMIC.
> 

Yes. this is dedicated single-enable-pin.

> >                compatible = "regulator-fixed";
> >                regulator-name = "usbdrd31_dwc3-vbus";
> >                regulator-min-microvolt = <5000000>; @@ -75,7 +75,7 @@
> > usb_phy0: usb-phy0 {
> >                 vbus-supply = <&usbdrd31_dwc3_vbus>;
> >         };
> >
> 
> ...
> 
> >>>>
> >>>> That's a bit too much of dummies. This is heavily incomplete. You
> >>>> need to bring back the PMIC first.
> >>>>
> >>>
> >>> Presently, relying on USB LDOs being enabled by the bootloader in
> >>> this automotive SoC. However, we understand the concern and it is
> >>> added in case if anyone wants to use implemented PMIC in future. For
> >>> now, would like to proceed with the dummy regulators to enable the
> >>> required USB
> >> features.
> >>
> >> And I don't see the point of these dummies. Solves nothing.
> >>
> >
> > Are you expecting details as mentioned in above section in commit
> message?
> > However, we have mentioned these details in cover letter.
> 
> No, I am expecting proper PMIC to be represented here. One dummy
> regulator during the fast development phase is okay. Dummy added by
> community contributors without resources and schematics would also fly.
> 
> But Samsung, with all the resources, schematics doing development since
> 2023 and still adding 20 dummies to every device? Nope, no, sorry.
> 
> Please start doing this properly. Look how entire new SoC was upstreamed
> by Linaro:
> https://lore.kernel.org/all/20231121-topic-sm8650-upstream-dt-v3-0-
> db9d0507ffd3@linaro.org/
> 
> Or something newer by Qualcomm:
> https://lore.kernel.org/linux-arm-msm/?q=s%3Aglymur
> 

Appreciated for the references.

As you might know, the regulator control and power‑management architecture 
has changed in recent Exynos SoCs. It is now controlled by the ACPM/APM core, and 
the PMIC is interfaced over SPMI (instead of the legacy I2C interface). I am checking 
internally how to implement this, and it may take a bit longer to have the full recipe 
ready to add an actual regulator.

USB is one of the critical IP blocks that needs be enabled to allow the rest of the 
team’s workflow over USB (e.g., enabling automation via USB for testing, etc.).

If these changes can be accommodated, it would be great. In the meantime, 
I will continue working internally to see how we can push the missing pieces upstream.

> 
> Best regards,
> Krzysztof

Thank you.

Regards,
Pritam