Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support

From: "Ze Huang" <huang.ze@linux.dev>
To: "Chukun Pan" <amadeus@jmu.edu.cn>, <thinh.nguyen@synopsys.com>
Cc: <dlan@kernel.org>, <gregkh@linuxfoundation.org>,
	<huang.ze@linux.dev>, <linux-kernel@vger.kernel.org>,
	<linux-riscv@lists.infradead.org>, <linux-usb@vger.kernel.org>,
	<spacemit@lists.linux.dev>
Subject: Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support
Date: Fri, 20 Mar 2026 15:45:20 +0800	[thread overview]
Message-ID: <DH7FXPBMB1K5.28IT6DZQ280ZV@linux.dev> (raw)
In-Reply-To: <20260320063621.1204038-1-amadeus@jmu.edu.cn>

On Fri Mar 20, 2026 at 2:36 PM CST, Chukun Pan wrote:
> Hi,
>
>> In my previous response, I noted to pass the name/id that best match
>> your platform in the dwc3_generic_config. This structure is passed as
>> private data corresponding to your k1 platform compatible string. That
>> should solve the naming issue (i.e. you can keep the name "vbus").
>
> Thank you for your suggestion, I will change it to match compatible.
>
>> > Do I need to check if it's in host mode?
>>
>> Is your k1 a DRD controller, and that it can operate in device mode?
>> If so, does it save power to disable the regulator while operating in
>> device mode?
>
> It is a DRD controller that supports switching between Host and Device
> modes. I will change it to enable regulator only in Host mode.
>
>> > > Also do we want to disable the regulator on system suspend? If so,
>> > > we may need a regulator handle.
>> > 
>> > I'll add it if you think it's necessary.
>> >
>> Same comment as above, but this will be more involved. E.g. you may only
>> want to disable the vbus when remote wakeup is disabled and power saving
>> is more essential (disabling vbus will disconnect the device).
>
> I will consider implementing it in the future.
>
> Thanks,
> Chukun

Hi Chukun,

I don't think it's a good idea to tie this optional VBUS regulator
implementation to the SpacemiT K1 platform.

While the K1 SoC does have a DRD controller, current boards in the wild
(like Jupiter[1], OrangePi RV2[2], and Banana Pi F3[3]) all route this
port to an onboard hub[4][5]. IMHO, managing the downstream VBUS regulator
via the onboard_usb_dev driver is the correct approach for us.

[1] https://github.com/milkv-jupiter/jupiter-files/blob/main/hardware/v1_0/jupiter-sch-v1_0.pdf (page 20)
[2] https://drive.google.com/drive/folders/1pcI_U0C3VJKTCg8A1zj08CwNbohnONSR (page 16)
[3] https://drive.google.com/file/d/19iLJ5xnCB_oK8VeQjkPGjzAn39WYyylv/view (page 24)
[4] https://www.lcsc.com/datasheet/C209756.pdf
[5] https://www.lcsc.com/datasheet/C157362.pdf

K1 platform currently does not need this feature here.

Considering the role switch, I think it would be better to hold off on this
until there is an actual board/user that relies on it.

Thanks,
Ze

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv