topic Re: Kernel panic when disabling usb gadget in i.MX Processors

Kernel panic when disabling usb gadget

chris_f — Thu, 17 Dec 2020 14:09:37 GMT

I'm using kernel 4.9.88 on an iMX6ULL.

Sometimes, when disabling the usb gadget (by echo "" > UDC) the module locks completely.

I found this patch from @PeterChen for kernel 5.4:

https://patches.linaro.org/patch/223191/

and note that a similar problem was reported for kernel 4.4 (though patch was rejected) so assume it's the same issue in 4.9:

https://www.spinics.net/lists/linux-usb/msg159075.html

Could someone advise how to back-port Peter's patch to 4.9.88?

I can see what needs applying to udc/core.c but can't see yet where the usb_gadget structure is created so I can add the irq member.

Re: Kernel panic when disabling usb gadget

Zhiming_Liu — Fri, 18 Dec 2020 02:43:30 GMT

As patch shows,the gadget is in

/include/linux/usb/gadget.h

Zhiming

Re: Kernel panic when disabling usb gadget

chris_f — Fri, 18 Dec 2020 08:00:49 GMT

Thanks Zhiming but I can't see where the new member gadget.irq is set?

There's a struct fsl_udc in fsl_udc_core which also has an irq member (and a gadget struct). That is set with platform_get_irq in fsl_udc_probe.

The patch creates a new member gadget.irq but it's never set?

Re: Kernel panic when disabling usb gadget

Zhiming_Liu — Mon, 21 Dec 2020 02:04:26 GMT

Yes, I saw the source code and it isn't used in fsl_udc_remove.

Re: Kernel panic when disabling usb gadget

chris_f — Thu, 31 Dec 2020 11:13:23 GMT

I've now found the cause of the problem (the patch from @PeterChen isn't relevant).

It is not a kernel panic, it's a kernel lock up in the ChipIdea udc driver.

The function hw_ep_flush never returns. It is waiting for the hardware to complete endpoint flush that never happens.

https://elixir.bootlin.com/linux/latest/source/drivers/usb/chipidea/udc.c#L101

I've fixed this lock up by simply adding a timeout to that loop. If the flush doesn't complete we just continue as if it had. The next connection still works.

Further testing shows that there are other lock conditions that can occur (approx 1 in 200 connections) during connection/disconnection. There are a number of other loops in that code that will not exit unless the hardware complies.

I don't know if this hardware problem exists in other implementations using the ChipIdea driver but I can recreate it on multiple boards.