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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 04/03/2026 08:46, pritam.sutar@samsung.com wrote:
> 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.

I did not say anything odd about the process. You should have done
ACPM/APM/SPMI much earlier, because PMIC is a necessary early step in
upstreaming.

Your explanation feels like you are surprised.

> 
> 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.).

PMIC is before USB...

> 
> 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.

Sorry, I am not taking ~22 phandles to a dummy regulator.

Best regards,
Krzysztof