On Fri, Jun 11, 2021 at 9:22 AM <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx>
> Reported-by: kernel test robot <lkp@xxxxxxxxx>
> 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
