Re: [PATCH] usb: cdns3: attempt to fix Kconfig dependencies

Greg Kroah-Hartman
2026-04-03T08:54:47Z

On Fri, Apr 03, 2026 at 03:50:45PM +0800, Peter Chen (CIX) wrote:
> On 26-04-02 16:09:55, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > The way that dependencies between host and gadget mode, as well as cdns3
> > and cdnsp were handled was rather fragile before commit 6076388ca1ed
> > ("usb: cdns3: Add USBSSP platform driver support").
> >
> > After those changes, I get randconfig build failures:
> >
> > arm-linux-gnueabi-ld: drivers/usb/cdns3/cdnsp-gadget.o: in function `__cdnsp_gadget_init':
> > cdnsp-gadget.c:(.text+0x12da): undefined reference to `cdns_drd_gadget_on'
> > arm-linux-gnueabi-ld: drivers/usb/cdns3/cdnsp-gadget.o: in function `cdnsp_gadget_pullup':
> > cdnsp-gadget.c:(.text+0x3030): undefined reference to `cdns_clear_vbus'
> > arm-linux-gnueabi-ld: cdnsp-gadget.c:(.text+0x3138): undefined reference to `cdns_set_vbus'
> > arm-linux-gnueabi-ld: drivers/usb/cdns3/cdnsp-gadget.o: in function `cdnsp_gadget_exit':
> > cdnsp-gadget.c:(.text+0xe0): undefined reference to `cdns_drd_gadget_off'
> >
> > and I see additional configurations that are broken. The main problem
> > here is that the 'common' module links against both host and gadget
> > support if they are enabled, but there are insufficient protections
> > agains it being built-in if only one of them is built-in and the other
> > is in a loadable module, causing link failures.
> >
> > The use of IS_REACHABLE() in gadget-export.h works around a similar
> > problem if one of cdns3 and cdnsp is built-in but the other one is
> > =m. This one is worse because instead of a clear link failure, the
> > logic just makes it not work at all despite support being enabled.
> >
> > To improve this mess, throw out both the Makefile hacks and the
> > IS_REACHABLE() hack and replace these with regular Kconfig dependencies
> > that ensure each driver is only enabled when its dependencies are there,
> > as we do in most other drivers. The main downside here is that there is no
> > good way to have built-in gadget support on cdn3 along with USB=m. Fixing
> > this part proper would require cleaning up the code to turn the 'common'
> > parts into a library module that only gets called by the other drivers
> > but does not interact with either host or gadget support itself.
> >
> > Another problem that is not solved by this patch is the way that
> > platform specific glue logic in this driver relies on having
> > a soc specific device as the parent of a generic child, instead of
> > the specific driver just calling into a common helper module.
> > This may be impossible to fix without breaking the DT bindings.
> >
> > Fixes: 6076388ca1ed ("usb: cdns3: Add USBSSP platform driver support")
>
> Hi Arnd,
>
> Thanks for fixing it, I am sorry for taking your effort debug it.
>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > TBH, I would be more comfortable with reverting 6076388ca1ed altogether
> > and asking for a new version with the proper fixups included along
> > with more testing for the next merge window.
>
> It depends on Greg, I am okay for both ways. If Greg reverts the patch,
> I will do below improvements and adapts for most of your changes for v3
> patch.

I'll be glad to revert if you want me to, just let me know.

thanks,

greg k-h