From: "Ze Huang" <huang.ze@linux.dev>
To: "Chukun Pan" <amadeus@jmu.edu.cn>, <huang.ze@linux.dev>
Cc: <dlan@kernel.org>, <gregkh@linuxfoundation.org>,
<linux-kernel@vger.kernel.org>, <linux-riscv@lists.infradead.org>,
<linux-usb@vger.kernel.org>, <spacemit@lists.linux.dev>,
<thinh.nguyen@synopsys.com>
Subject: Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support
Date: Fri, 20 Mar 2026 23:05:33 +0800 [thread overview]
Message-ID: <DH7PARAFZS7V.1YIE6OED3NA6C@linux.dev> (raw)
In-Reply-To: <20260320104026.1350571-1-amadeus@jmu.edu.cn>
On Fri Mar 20, 2026 at 6:40 PM CST, Chukun Pan wrote:
> Hi,
>
>> I think it's better to align the driver with the actual hardware. I'm not
>> opposed to managing any regulators in usb host/device drivers. But if we
>> do have an onboard hub, and regulator belongs to the downstream ports of
>> the hub, then it's hub's job, right?
>
>> Many boards leave gpio controlled regulators always on, that's what we
>> want to solve. If we have to choose the parent of these regulators, why
>> not put them in the correct hierarchy?
>
> I think we can manage the regulator in the USB host driver first,
> and then use it after the onboard_usb_dev driver has been merged.
> This is better than keeping the regulator always on.
>
>> If such a board really need the regulator, IMO, your patch is the way to go.
>>
>> OrangePi haven't released the schematic yet.
>>
>> That's what I could find [1], which seems similar to RV2.
>
> There is no onboard USB hub. Just check the image:
>
> http://www.orangepi.org/img/r2s/details/17.png
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-R2S.html
>
That's fine, thanks.
> Thanks,
> Chukun
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: "Ze Huang" <huang.ze@linux.dev>
To: "Chukun Pan" <amadeus@jmu.edu.cn>, <huang.ze@linux.dev>
Cc: <dlan@kernel.org>, <gregkh@linuxfoundation.org>,
<linux-kernel@vger.kernel.org>, <linux-riscv@lists.infradead.org>,
<linux-usb@vger.kernel.org>, <spacemit@lists.linux.dev>,
<thinh.nguyen@synopsys.com>
Subject: Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support
Date: Fri, 20 Mar 2026 23:05:33 +0800 [thread overview]
Message-ID: <DH7PARAFZS7V.1YIE6OED3NA6C@linux.dev> (raw)
In-Reply-To: <20260320104026.1350571-1-amadeus@jmu.edu.cn>
On Fri Mar 20, 2026 at 6:40 PM CST, Chukun Pan wrote:
> Hi,
>
>> I think it's better to align the driver with the actual hardware. I'm not
>> opposed to managing any regulators in usb host/device drivers. But if we
>> do have an onboard hub, and regulator belongs to the downstream ports of
>> the hub, then it's hub's job, right?
>
>> Many boards leave gpio controlled regulators always on, that's what we
>> want to solve. If we have to choose the parent of these regulators, why
>> not put them in the correct hierarchy?
>
> I think we can manage the regulator in the USB host driver first,
> and then use it after the onboard_usb_dev driver has been merged.
> This is better than keeping the regulator always on.
>
>> If such a board really need the regulator, IMO, your patch is the way to go.
>>
>> OrangePi haven't released the schematic yet.
>>
>> That's what I could find [1], which seems similar to RV2.
>
> There is no onboard USB hub. Just check the image:
>
> http://www.orangepi.org/img/r2s/details/17.png
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-R2S.html
>
That's fine, thanks.
> Thanks,
> Chukun
next prev parent reply other threads:[~2026-03-20 15:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 8:00 [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support Chukun Pan
2026-03-16 8:00 ` Chukun Pan
2026-03-17 4:15 ` Ze Huang
2026-03-17 4:15 ` Ze Huang
2026-03-18 0:29 ` Thinh Nguyen
2026-03-18 0:29 ` Thinh Nguyen
2026-03-18 6:30 ` Chukun Pan
2026-03-18 6:30 ` Chukun Pan
2026-03-18 23:15 ` Thinh Nguyen
2026-03-18 23:15 ` Thinh Nguyen
2026-03-19 6:26 ` Chukun Pan
2026-03-19 6:26 ` Chukun Pan
2026-03-19 21:46 ` Thinh Nguyen
2026-03-19 21:46 ` Thinh Nguyen
2026-03-20 6:36 ` Chukun Pan
2026-03-20 6:36 ` Chukun Pan
2026-03-20 7:45 ` Ze Huang
2026-03-20 7:45 ` Ze Huang
2026-03-20 8:18 ` Chukun Pan
2026-03-20 8:18 ` Chukun Pan
2026-03-20 9:50 ` Ze Huang
2026-03-20 9:50 ` Ze Huang
2026-03-20 10:40 ` Chukun Pan
2026-03-20 10:40 ` Chukun Pan
2026-03-20 15:05 ` Ze Huang [this message]
2026-03-20 15:05 ` Ze Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DH7PARAFZS7V.1YIE6OED3NA6C@linux.dev \
--to=huang.ze@linux.dev \
--cc=amadeus@jmu.edu.cn \
--cc=dlan@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=spacemit@lists.linux.dev \
--cc=thinh.nguyen@synopsys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.