lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YCRcIuCxB8nYi7/e@google.com>
Date:   Wed, 10 Feb 2021 14:20:18 -0800
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        devicetree@...r.kernel.org, Peter Chen <peter.chen@....com>,
        Stephen Boyd <swboyd@...omium.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Ravi Chandra Sadineni <ravisadineni@...omium.org>,
        Bastien Nocera <hadess@...ess.net>,
        linux-kernel@...r.kernel.org,
        Douglas Anderson <dianders@...omium.org>,
        linux-usb@...r.kernel.org, Mathias Nyman <mathias.nyman@...el.com>
Subject: Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for
 onboard hubs in probe()

Hi Krzysztof,

On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:
> On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:
> > Check during probe() if a hub supported by the onboard_usb_hub
> > driver is connected to the controller. If such a hub is found
> > create the corresponding platform device. This requires the
> > device tree to have a node for the hub with its vendor and
> > product id (which is not common for USB devices). Further the
> > platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.
> > 
> > Signed-off-by: Matthias Kaehlcke <mka@...omium.org>
> > ---
> > 
> > Changes in v5:
> > - patch added to the series
> > 
> >  drivers/usb/host/xhci-plat.c | 16 ++++++++++++++++
> >  include/linux/usb/hcd.h      |  2 ++
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> > index 4d34f6005381..e785fa109eea 100644
> > --- a/drivers/usb/host/xhci-plat.c
> > +++ b/drivers/usb/host/xhci-plat.c
> > @@ -15,6 +15,7 @@
> >  #include <linux/of.h>
> >  #include <linux/of_device.h>
> >  #include <linux/platform_device.h>
> > +#include <linux/usb/onboard_hub.h>
> >  #include <linux/usb/phy.h>
> >  #include <linux/slab.h>
> >  #include <linux/acpi.h>
> > @@ -184,6 +185,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
> >  	int			ret;
> >  	int			irq;
> >  	struct xhci_plat_priv	*priv = NULL;
> > +	struct device_node	*np;
> >  
> >  
> >  	if (usb_disabled())
> > @@ -356,6 +358,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
> >  	 */
> >  	pm_runtime_forbid(&pdev->dev);
> >  
> > +	np = usb_of_get_device_node(hcd->self.root_hub, hcd->self.busnum);
> > +	if (np && of_is_onboard_usb_hub(np)) {
> 
> This looks hackish... what if later we have something else than hub?
> Another if()?
> 
> What if hub could be connected to something else than XHCI controller?

In earlier versions this was standalone driver, which was more flexible and
didn't require cooperation from the XHCI driver:

https://lore.kernel.org/patchwork/patch/1313001/

Rob Herring raised objections about the DT bindings, since the USB hub would be
represented twice in the DT, once in the USB hierachry (with an explicit node or
implicitly) plus a node for the platform device for the new driver:

https://lore.kernel.org/patchwork/patch/1305395/
https://lore.kernel.org/patchwork/patch/1313000/

Alan Stern suggested to create the platform device in the XHCI platform driver:

https://lore.kernel.org/patchwork/patch/1313000/#1510227

I wasn't super happy about involving xhci-plat, but at least the code is minimal
and all the device specific stuff is handled by the onboard_usb_hub driver.

If you have better suggestions that might satisfy all parties please let us
know :)

Matthias

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ