On 7/26/22 10:25, Mattijs Korpershoek wrote: [...]
implementation, which would cover all such odd states for every other USB UDC mode of operation, not just fastboot ?
Implementing a platform_reset to reset the usb controller also works. I discussed this with Neil at [1] and he suggested to send the f_fastboot.c fix (this one) because it's generic and might fix issues for other boards.
So, should I abandon this version and go with the platform specific fix instead ?
[1] https://gitlab.com/baylibre/amlogic/atv/u-boot/-/commit/94c79b8226875babc203...
If your controller is responsible for causing the platform to fail to reboot, then I think it makes sense to do a fix either in the reset implementation for that platform, or the controller driver.
To be clear, the usb controller is *not* causing the whole platform to reboot. On do_reset(), the platform resets fine. However, the usb controller is *not* put in reset. Because of that, the host does not detect a USB disconnection. Which is what I'm trying to solve here.
Yes, this is how I understand the problem too.
Assume someone would run e.g. ums code, which would bring up the controller too, I suspect it would also cause the same reset issues. Which is why I wonder whether we shouldn't add this kind of fix into the reset handler for the platform itself.
If we do the generic fix, there is not really a point into implementing a platform specific reset. Note that on linux, when we run "reboot" the driver's remove() function takes care of usb reset.
Does that also work with sysrq-B or reboot -nf (one of the fast reboots) ?