patch "Revert "usb: gadget: fsl: Re-enable driver for ARM SoCs"" added to usb-linus

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 <[email protected]>

Reported-by kernel test robot <[email protected]>

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?

Quoted 13 lines · Arnd Bergmann

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.

Quoted 5 lines

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?

Exactly. The USB IP on several i.MX devices comes from ChipIdea.

Prior to using devicetree, we had the fsl_mxc_udc driver to handle the gadget side.

Since i.MX has been converted to a DT-only platform, we no longer need fsl_mxc_udc, as
drivers/usb/chipidea is used nowadays.

Quoted 42 lines

-----Original Message-----
From: Arnd Bergmann <[email protected]>
Sent: Friday, June 11, 2021 10:43 AM
To: Fabio Estevam <[email protected]>
Cc: gregkh <[email protected]>; Felipe Balbi <[email protected]>; Joel Stanley <[email protected]>; Leo Li <[email protected]>; kbuild test robot <[email protected]>; Peter Chen <[email protected]>; Ran Wang <[email protected]>; Stephen Rothwell <[email protected]>; Shawn Guo <[email protected]>; # 3.4.x <[email protected]>; Guennadi Liakhovetski <[email protected]>
Subject: Re: patch "Revert "usb: gadget: fsl: Re-enable driver for ARM SoCs"" added to usb-linus

Quoted 8 lines · Fabio Estevam

Quoted 6 lines · Arnd Bergmann

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.

Quoted 19 lines

Quoted 8 lines

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.

Quoted 5 lines

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?

Exactly. The USB IP on several i.MX devices comes from ChipIdea.

Prior to using devicetree, we had the fsl_mxc_udc driver to handle the gadget side.

Quoted 6 lines

Quoted 2 lines

Since i.MX has been converted to a DT-only platform, we no longer need fsl_mxc_udc, as drivers/usb/chipidea is used nowadays.

Ok, good, so the simples solution I suppose is to remove the remaining bits that Guennadi added when he wrote the removed driver in 54e4026b64a9, and then re-apply Joel's patch.

I can provide a patch for this.

Quoted 3 lines

Alternatively, it might be possible change the chipidea driver to work on ls1021a and ls1012a, assuming that they use the same hardware block as i.MX.

It is also used on many legacy FSL PowerPC SoCs. I agree with the direction, but it does require some effort to make sure it works on all these legacy platforms. I think Ran Wang had tried to do that, but not completed due to bandwidth issue.

Quoted 5 lines

Either way, it would be good to test the changes on at least one of these two platforms.

Arnd

The fsl_mxc_udc driver was originally developed as a part of a DENX project, adding Marek to CC to have them check internally what their preferences and requirements might be.