From: Matthias Kaehlcke <mka@chromium.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Mathias Nyman <mathias.nyman@intel.com>,
Felipe Balbi <balbi@kernel.org>,
devicetree@vger.kernel.org, Peter Chen <peter.chen@kernel.org>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
Bastien Nocera <hadess@hadess.net>,
Ravi Chandra Sadineni <ravisadineni@chromium.org>,
Michal Simek <michal.simek@xilinx.com>,
Douglas Anderson <dianders@chromium.org>,
Roger Quadros <rogerq@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Stephen Boyd <swboyd@chromium.org>,
Dmitry Osipenko <digetx@gmail.com>,
Fabio Estevam <festevam@gmail.com>
Subject: Re: [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe()
Date: Wed, 20 Oct 2021 14:01:21 -0700 [thread overview]
Message-ID: <YXCDobJSuytwthoA@google.com> (raw)
In-Reply-To: <20211020203720.GA1137200@rowland.harvard.edu>
On Wed, Oct 20, 2021 at 04:37:20PM -0400, Alan Stern wrote:
> On Wed, Oct 20, 2021 at 01:27:40PM -0700, Matthias Kaehlcke wrote:
> > Hi Mathias,
> >
> > On Wed, Oct 20, 2021 at 04:05:37PM +0300, Mathias Nyman wrote:
> > > If separate devices for controlling onboard hub power is the right solution then
> > > how about creating the onboard hub device in usb_add_hcd() (hcd.c), and
> > > store it in struct usb_hcd.
> > >
> > > A bit like how the roothub device is created, or PHYs are tuned.
> >
> > Sure, that sounds feasible, even better if it's handled in a single place
> > and different types of controllers don't have to add support separately.
>
> Bear in mind that this would prevent you from working with onboard
> non-root hubs.
My goal is to (architecturally) support nested hubs, but TBH I haven't
looked much into such a configuration since I don't have hardware for
testing. My assumption was that support for onboard hubs connected to
non-root hubs whould have to be added to the generic hub driver.
Could you elaborate in how far you think it would be different for
xhci_plat vs generic hcd?
next prev parent reply other threads:[~2021-10-20 21:02 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 19:52 [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
2021-08-13 19:52 ` [PATCH v16 1/7] " Matthias Kaehlcke
2021-11-11 23:31 ` Doug Anderson
2021-11-16 2:08 ` Matthias Kaehlcke
2021-08-13 19:52 ` [PATCH v16 2/7] of/platform: Add stubs for of_platform_device_create/destroy() Matthias Kaehlcke
2021-08-13 19:52 ` [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed Matthias Kaehlcke
2021-08-26 6:45 ` Roger Quadros
2021-08-26 7:56 ` Krzysztof Kozlowski
2021-08-13 19:52 ` [PATCH v16 4/7] arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM Matthias Kaehlcke
2021-08-13 19:52 ` Matthias Kaehlcke
2021-08-26 6:46 ` Roger Quadros
2021-08-26 6:46 ` Roger Quadros
2021-08-13 19:52 ` [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on' Matthias Kaehlcke
2021-08-13 19:52 ` Matthias Kaehlcke
2021-08-26 6:46 ` Roger Quadros
2021-08-26 6:46 ` Roger Quadros
2021-11-11 23:48 ` Doug Anderson
2021-11-11 23:48 ` Doug Anderson
2021-11-16 18:07 ` Matthias Kaehlcke
2021-11-16 18:07 ` Matthias Kaehlcke
2021-08-13 19:52 ` [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe() Matthias Kaehlcke
2021-10-20 13:05 ` Mathias Nyman
2021-10-20 20:27 ` Matthias Kaehlcke
2021-10-20 20:37 ` Alan Stern
2021-10-20 21:01 ` Matthias Kaehlcke [this message]
2021-10-20 21:57 ` Alan Stern
2021-08-13 19:52 ` [PATCH v16 7/7] arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub Matthias Kaehlcke
2021-09-21 17:08 ` [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
2021-10-14 21:38 ` Doug Anderson
2021-10-15 6:39 ` Greg Kroah-Hartman
2021-10-19 16:04 ` Fabrice Gasnier
2021-10-19 22:10 ` Matthias Kaehlcke
2021-10-20 6:21 ` Michal Simek
2021-10-20 17:41 ` Matthias Kaehlcke
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=YXCDobJSuytwthoA@google.com \
--to=mka@chromium.org \
--cc=balbi@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=digetx@gmail.com \
--cc=festevam@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=mathias.nyman@linux.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.