From: Matthias Kaehlcke <mka@chromium.org>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alan Stern <stern@rowland.harvard.edu>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Mathias Nyman <mathias.nyman@intel.com>,
Felipe Balbi <balbi@kernel.org>,
linux-kernel@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>,
Stephen Boyd <swboyd@chromium.org>,
Peter Chen <peter.chen@kernel.org>,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
Douglas Anderson <dianders@chromium.org>,
Roger Quadros <rogerq@kernel.org>,
Michal Simek <michal.simek@xilinx.com>,
Ravi Chandra Sadineni <ravisadineni@chromium.org>,
Bastien Nocera <hadess@hadess.net>
Subject: Re: [PATCH v17 1/7] usb: misc: Add onboard_usb_hub driver
Date: Thu, 30 Dec 2021 12:17:26 -0800 [thread overview]
Message-ID: <Yc4T1qSkcRF2iBVg@google.com> (raw)
In-Reply-To: <07781322-3632-7d63-0da8-a651a438a3ff@gmail.com>
On Mon, Dec 20, 2021 at 11:05:28PM +0300, Dmitry Osipenko wrote:
> 16.11.2021 23:07, Matthias Kaehlcke пишет:
> > +static const struct usb_device_id onboard_hub_id_table[] = {
> > + { USB_DEVICE(VENDOR_ID_REALTEK, 0x0411) }, /* RTS0411 USB 3.0 */
> > + { USB_DEVICE(VENDOR_ID_REALTEK, 0x5411) }, /* RTS5411 USB 2.0 */
> > + {},
> > +};
>
> RTS5411 two times in the comments?
One time, the other is RTS0511
> Internet suggests that RTS5411 is USB 3.0
Correct, however the chip internally has two hubs, one for USB2 and one for
USB3:
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. 4-Port USB 3.1 Hub
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. 4-Port USB 2.1 Hub
> Are these hubs expected to be powered-on only when upstream port is
> enabled? Shouldn't runtime PM be used for that somehow?
In the general case I would expect that a onboard hub is connected to a port
that is enabled. For now I think it's fine to power the hub always when the
system is running (which is also the current situation with using always-on
regulators). If someone has an actual use case where the upstream port can
be disabled they can add support for that later.
next prev parent reply other threads:[~2021-12-30 20:17 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 20:07 [PATCH v17 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
2021-11-16 20:07 ` [PATCH v17 1/7] " Matthias Kaehlcke
2021-11-18 0:11 ` Doug Anderson
2021-11-18 17:52 ` Matthias Kaehlcke
2021-12-10 16:51 ` Matthias Kaehlcke
2021-11-18 18:13 ` kernel test robot
2021-11-18 18:13 ` kernel test robot
2021-11-18 18:36 ` Matthias Kaehlcke
2021-11-18 18:36 ` Matthias Kaehlcke
2021-12-20 20:05 ` Dmitry Osipenko
2021-12-30 20:17 ` Matthias Kaehlcke [this message]
2022-01-01 12:23 ` Dmitry Osipenko
2022-01-12 19:00 ` Matthias Kaehlcke
2021-11-16 20:07 ` [PATCH v17 2/7] of/platform: Add stubs for of_platform_device_create/destroy() Matthias Kaehlcke
2021-11-22 17:43 ` Matthias Kaehlcke
2021-12-01 22:31 ` Matthias Kaehlcke
2021-11-16 20:07 ` [PATCH v17 3/7] usb: core: hcd: Create platform devices for onboard hubs in probe() Matthias Kaehlcke
2021-11-18 0:03 ` Doug Anderson
2021-11-16 20:07 ` [PATCH v17 4/7] arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub Matthias Kaehlcke
2021-11-18 0:03 ` Doug Anderson
2021-11-18 18:43 ` Matthias Kaehlcke
2021-11-16 20:07 ` [PATCH v17 5/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed Matthias Kaehlcke
2021-11-16 20:07 ` Matthias Kaehlcke
2021-11-16 20:07 ` [PATCH v17 6/7] arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM Matthias Kaehlcke
2021-11-16 20:07 ` Matthias Kaehlcke
2021-11-16 20:07 ` [PATCH v17 7/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on' Matthias Kaehlcke
2021-11-16 20:07 ` Matthias Kaehlcke
2021-11-17 2:21 ` Alan Stern
2021-11-17 2:21 ` Alan Stern
2021-11-18 17:16 ` Matthias Kaehlcke
2021-11-18 17:16 ` Matthias Kaehlcke
2021-12-16 23:56 ` Matthias Kaehlcke
2021-12-16 23:56 ` Matthias Kaehlcke
2021-12-17 0:47 ` Dmitry Osipenko
2021-12-17 0:47 ` Dmitry Osipenko
2021-12-20 18:44 ` Matthias Kaehlcke
2021-12-20 18:44 ` Matthias Kaehlcke
2021-12-20 19:59 ` Dmitry Osipenko
2021-12-20 19:59 ` Dmitry Osipenko
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=Yc4T1qSkcRF2iBVg@google.com \
--to=mka@chromium.org \
--cc=balbi@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=digetx@gmail.com \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hadess@hadess.net \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=michal.simek@xilinx.com \
--cc=peter.chen@kernel.org \
--cc=ravisadineni@chromium.org \
--cc=robh+dt@kernel.org \
--cc=rogerq@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=swboyd@chromium.org \
/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.