From: Matthias Kaehlcke <mka@chromium.org>
To: Doug Anderson <dianders@chromium.org>
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>,
LKML <linux-kernel@vger.kernel.org>,
Ravi Chandra Sadineni <ravisadineni@chromium.org>,
Bastien Nocera <hadess@hadess.net>,
Linux USB List <linux-usb@vger.kernel.org>,
Roger Quadros <rogerq@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Michal Simek <michal.simek@xilinx.com>,
Stephen Boyd <swboyd@chromium.org>,
Peter Chen <peter.chen@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Souradeep Chowdhury <quic_schowdhu@quicinc.com>
Subject: Re: [PATCH v23 2/3] usb: misc: Add onboard_usb_hub driver
Date: Mon, 27 Jun 2022 12:52:32 -0700 [thread overview]
Message-ID: <YroKgNPY4YHh0kGf@google.com> (raw)
In-Reply-To: <CAD=FV=XHnRNQQo8i95ROiZPOGqAD_=FfU0uzy83Vigb+Xsr4XQ@mail.gmail.com>
On Fri, Jun 24, 2022 at 01:33:25PM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, Jun 22, 2022 at 2:49 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
> > index 4c5ddbd75b7e..7fd40183a395 100644
> > --- a/drivers/usb/misc/Kconfig
> > +++ b/drivers/usb/misc/Kconfig
> > @@ -295,3 +295,19 @@ config BRCM_USB_PINMAP
> > This option enables support for remapping some USB external
> > signals, which are typically on dedicated pins on the chip,
> > to any gpio.
> > +
> > +config USB_ONBOARD_HUB
> > + bool "Onboard USB hub support"
>
> The above needs to be "tristate", not bool.
right, thanks!
> Weirdly the way you have it if you set "CONFIG_USB=m" and
> "CONFIG_USB_ONBOARD_HUB=y" you don't get any compile errors, but also
> the onboard usb hub doesn't even get compiled (!). Once you switch to
> tristate then setting "CONFIG_USB=m" will force the onboard hub to be
> a module too (since it's underneath the "if" in the Kconfig).
>
> ...ugh, but once you do that then you start getting compile errors if
> you have "CONFIG_USB=y" and "CONFIG_USB_ONBOARD_HUB=m". I guess that
> can be fixed with something like this
>
> -usbcore-$(CONFIG_USB_ONBOARD_HUB) += ../misc/onboard_usb_hub_pdevs.o
> +ifdef CONFIG_USB_ONBOARD_HUB
> +usbcore-y += ../misc/onboard_usb_hub_pdevs.o
> +endif
Thanks for testing and the suggestion!
> Given the problems we've had in the past, please make sure you test
> with all combinations of "=y" and "=m" for CONFIG_USB and
> CONFIG_USB_ONBOARD_HUB. Note that on sc7180-trogdor devices if you
> want CONFIG_USB to be a module don't forget to also set
> CONFIG_USB_DWC3=m or DWC3 will force you to gadget mode...
ack
I think I did an 'allmodconfig' build only test, but that didn't really help
in this case ...
> > +/**
> > + * onboard_hub_create_pdevs -- create platform devices for onboard USB hubs
> > + * @parent_hub : parent hub to scan for connected onboard hubs
> > + * @pdev_list : list of onboard hub platform devices owned by the parent hub
> > + *
> > + * Creates a platform device for each supported onboard hub that is connected to
> > + * the given parent hub. The platform device is in charge of initializing the
> > + * hub (enable regulators, take the hub out of reset, ...) and can optionally
> > + * control whether the hub remains powered during system suspend or not.
> > +
> > + * To keep track of the platform devices they are added to
> > + * a list that is owned by the parent hub.
>
> super nitty, but the above two lines of comment could be word-wrapped better.
Sure, I probably rephrased that at some point and forgot to re-wrap.
> > + */
> > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > +{
> > + int i;
> > + struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
>
> As per my response on v22, would you be willing to rename that to
> "parent_hcd"? I'll probably still confuse myself next time I read this
> function, but at least maybe this will help me recognize more quickly
> that this isn't necessarily the child's hcd in the case of the root
> hub.
See my reply on v22, I think 'parent_hcd' could still be confusing and it
might be best to have a more detailed description of the problem. In any
case I'm open to discuss it :)
next prev parent reply other threads:[~2022-06-27 19:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-22 21:49 [PATCH v23 0/3] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
2022-06-22 21:49 ` [PATCH v23 1/3] of/platform: Add stubs for of_platform_device_create/destroy() Matthias Kaehlcke
2022-06-22 21:49 ` [PATCH v23 2/3] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
2022-06-24 20:33 ` Doug Anderson
2022-06-27 19:52 ` Matthias Kaehlcke [this message]
2022-06-22 21:49 ` [PATCH v23 3/3] usb: core: hub: Create platform devices for onboard hubs in hub_probe() 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=YroKgNPY4YHh0kGf@google.com \
--to=mka@chromium.org \
--cc=balbi@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=frowand.list@gmail.com \
--cc=geert+renesas@glider.be \
--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=quic_schowdhu@quicinc.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).