linux-kernel - Re: [PATCH v13 3/5] usb: xhci: Add support for Renesas controller with memory

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]

Date:   Tue, 19 May 2020 09:44:15 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     Anders Roxell <anders.roxell@...aro.org>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Christian Lamparter <chunkeey@...glemail.com>,
        John Stultz <john.stultz@...aro.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Andreas Böhler <dev@...ehler.at>,
        USB list <linux-usb@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v13 3/5] usb: xhci: Add support for Renesas controller
 with memory

On Tue, May 19, 2020 at 6:53 AM Vinod Koul <vkoul@...nel.org> wrote:
> On 19-05-20, 00:37, Anders Roxell wrote:
> > On Mon, 18 May 2020 at 21:57, Vinod Koul <vkoul@...nel.org> wrote:
> > > On 18-05-20, 19:53, Anders Roxell wrote:
> > > > On Wed, 6 May 2020 at 08:01, Vinod Koul <vkoul@...nel.org> wrote:
> > > > >
> > > > > Some rensas controller like uPD720201 and uPD720202 need firmware to be
> > > > > loaded. Add these devices in pci table and invoke renesas firmware loader
> > > > > functions to check and load the firmware into device memory when
> > > > > required.
> > > > >
> > > > > Signed-off-by: Vinod Koul <vkoul@...nel.org>
> > > >
> > > > Hi, I got a build error when I built an arm64 allmodconfig kernel.
> > >
> > > Thanks for this. This is happening as we have default y for USB_XHCI_PCI
> > > and then we make USB_XHCI_PCI_RENESAS=m. That should be not allowed as
> > > we export as symbol so both can be inbuilt or modules but USB_XHCI_PCI=y
> > > and USB_XHCI_PCI_RENESAS=m cant. While it is valid that USB_XHCI_PCI=y|m
> > > and USB_XHCI_PCI_RENESAS=n
> > >
> > > So this seems to get fixed by below for me. I have tested with
> > >  - both y and m (easy)
> > >  - make USB_XHCI_PCI_RENESAS=n, USB_XHCI_PCI=y|m works
> > >  - try making USB_XHCI_PCI=y and USB_XHCI_PCI_RENESAS=m, then
> > >    USB_XHCI_PCI=m by kbuild :)
> > >  - try making USB_XHCI_PCI=m and USB_XHCI_PCI_RENESAS=y, kbuild gives
> > >    error prompt that it will be m due to depends
> > >
> > > Thanks to all the fixes done by Arnd which pointed me to this. Pls
> > > verify
> >
> > I was able to build an arm64 allmodconfig kernel with this change.
>
> I will send the formal patch and add your name in reported and
> tested. Thanks for the quick verification

I just checked the patch and I think this will work correctly in all cases,
but it still seems a bit backwards:

> > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > > index b5c542d6a1c5..92783d175b3f 100644
> > > --- a/drivers/usb/host/Kconfig
> > > +++ b/drivers/usb/host/Kconfig
> > > @@ -40,11 +40,11 @@ config USB_XHCI_DBGCAP
> > >  config USB_XHCI_PCI
> > >         tristate
> > >         depends on USB_PCI
> > > +       depends on USB_XHCI_PCI_RENESAS || !USB_XHCI_PCI_RENESAS
> > >         default y
> > >
> > >  config USB_XHCI_PCI_RENESAS
> > >         tristate "Support for additional Renesas xHCI controller with firwmare"
> > > -       depends on USB_XHCI_PCI
> > >         ---help---
> > >           Say 'Y' to enable the support for the Renesas xHCI controller with
> > >           firwmare. Make sure you have the firwmare for the device and
> > >

I think it would have been better to follow the normal driver abstraction here
and make the renesas xhci a specialized version of the xhci driver with
its own platform_driver instance that calls into the generic xhci_pci module,
rather than having the generic code treat it as a quirk.

That would be more like how we handle all the ehci and ohci variants, though
I'm not sure how exactly it would work with two drivers having pci_device_id
tables with non-exclusive members. Presumably the generic driver would
still have to know that it needs to fail its probe() function on devices that
need the firmware.

        Arnd