[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP6Zq1gFnLYspn5+dYbSSOicZibCTbF9Z8bmNV+_HDP3=nLp8A@mail.gmail.com>
Date: Mon, 18 Jul 2022 17:29:32 +0300
From: Tomer Maimon <tmaimon77@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Avi Fishman <avifishman70@...il.com>,
Tali Perry <tali.perry1@...il.com>,
Joel Stanley <joel@....id.au>,
Patrick Venture <venture@...gle.com>,
Nancy Yuen <yuenn@...gle.com>,
Benjamin Fair <benjaminfair@...gle.com>,
gregkh <gregkh@...uxfoundation.org>,
Alan Stern <stern@...land.harvard.edu>,
Tony Lindgren <tony@...mide.com>,
Felipe Balbi <felipe.balbi@...ux.intel.com>,
Juergen Gross <jgross@...e.com>,
Lukas Bulwahn <lukas.bulwahn@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
OpenBMC Maillist <openbmc@...ts.ozlabs.org>,
USB list <linux-usb@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
DTML <devicetree@...r.kernel.org>
Subject: Re: [PATCH v1 1/3] usb: host: npcm7xx: remove USB EHCI host reset sequence
Hi Arnd,
Thanks for your detailed explanation.
I will remove this modification in the next version.
On Mon, 18 Jul 2022 at 15:38, Arnd Bergmann <arnd@...db.de> wrote:
>
> On Mon, Jul 18, 2022 at 2:29 PM Tomer Maimon <tmaimon77@...il.com> wrote:
> >
> > config USB_EHCI_HCD_NPCM7XX
> > tristate "Support for Nuvoton NPCM7XX on-chip EHCI USB controller"
> > - depends on (USB_EHCI_HCD && ARCH_NPCM7XX) || COMPILE_TEST
> > + depends on (USB_EHCI_HCD && ARCH_NPCM7XX && RESET_NPCM) || COMPILE_TEST
> > default y if (USB_EHCI_HCD && ARCH_NPCM7XX)
> > help
> > Enables support for the on-chip EHCI controller on
>
> I would leave out this Kconfig change, there is really no need to enforce
> this specific dependency. It is expected that a device driver has dependencies
> on several other subsystems (irqchip, reset, pinctrl, clock, ....) and will only
> work if the required drivers are also built for the same kernel.
>
> Also, forcing the USB driver to be a loadable module when the reset driver
> is a module (rather than built-in) does not guarantee that they are initialized
> in the correct order. If only the USB driver is built-in and the reset driver is
> a module, or both are loadable modules and USB gets loaded first, then
> the probe() function should notice this and return -EPROBE_DEFER so
> it will be retried after the reset driver is successfully loaded.
>
> Arnd
Best regards,
Tomer
Powered by blists - more mailing lists