On Fri, Jun 11, 2021 at 9:22 AM gregkh@linuxfoundation.org wrote:
Turns out this breaks the build. We had numerous reports of problems from linux-next and 0-day about this not working properly, so revert it for now until it can be figured out properly.
The build errors are: arm-linux-gnueabi-ld: fsl_udc_core.c:(.text+0x29d4): undefined reference to `fsl_udc_clk_finalize' arm-linux-gnueabi-ld: fsl_udc_core.c:(.text+0x2ba8): undefined reference to `fsl_udc_clk_release' fsl_udc_core.c:(.text+0x2848): undefined reference to `fsl_udc_clk_init' fsl_udc_core.c:(.text+0xe88): undefined reference to `fsl_udc_clk_release'
Reported-by: Stephen Rothwell sfr@canb.auug.org.au Reported-by: kernel test robot lkp@intel.com Fixes: e0e8b6abe8c8 ("usb: gadget: fsl: Re-enable driver for ARM SoCs")
Adding Fabio and Guennadi to Cc.
I can see that the missing symbols were in a driver that got removed in commit a390bef7db1f ("usb: gadget: fsl_mxc_udc: Remove the driver").
If CONFIG_ARCH_MXC is disabled, these are stubbed out in the header file. These were added a long time ago by Guennadi Liakhovetski 54e4026b64a9 ("USB: gadget: Add i.MX3x support to the fsl_usb2_udc driver"). I also see that this patch added a few #ifdef CONFIG_ARCH_MXC checks to the driver that still remain today. This is clearly broken as it must be possible to use the same driver module on both SOC_LS1021A and i.MX using a runtime check.
I also don't see any i.MX variant actually using this driver, but instead see the dts files declaring fsl,imx27-usb devices, which bind to the drivers/usb/chipidea/ci_hdrc_imx.c driver. Is this one of those cases where we have two separate drivers for the same hardware, or is this for a different device?
Arnd