Hi Marcelo, Jonas, On 12/13/21 4:31 PM, Marcelo Roberto Jimenez wrote: > > Some people who received this message don't often get email from marcelo.jimenez@xxxxxxxxx. Learn why this is important <http://aka.ms/LearnAboutSenderIdentification> > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > Hi Jonas, > > Thank you for the quick response, I really appreciate it. > > On Mon, Dec 13, 2021 at 7:02 AM Jonas Bonn <jonas@xxxxxxxxxxx <mailto:jonas@xxxxxxxxxxx>> wrote: > > > Given that the patch that you want to revert is almost 3 years old, it's > a bit of a stretch to call this a regression. I suspect that a cleaner > way forward is to introduce some kind of quirk for your board. > > > Well, the board is basically the MPU, so if there is a hardware problem it would mean that it is a problem with the on chip peripheral. > > > I have a self-powered board where the USB suspend sequence works and > device add/remove works fine. So fundamentally, I suspect that the > driver is ok. > > > Maybe you have VBUS sensing enabled in your board. As I reported before, the VBUS sensing is not an option in this board. Nonetheless, the code in the kernel suggests that VBUS sensing is optional, since the presence of a VBUS sensing pin is explicitly tested in it. Is it possible to add a wire that connects VBUS to the right pin on the MPU ? Just to see if this has an impact or not ? > > I have not read the full USB spec, but if this is a fundamentally not resolvable problem, maybe we could have a configuration option, runtime or compile time, to enable or disable SUSPEND state, assuming that there is no problem with the original patch. > > In my particular application, it is more important to detect the disconnection, so that we can reconnect, than to enter SUSPEND. Whenever USB is not necessary, it will not be connected, so the energy saved will be very little in my case. > > My intention with this patch is also to provide a quick fix for anyone facing this problem, reverting is not necessarily the best long term solution, especially if the code is found to be correct. But assuming the chip USB controller has no design flaws, and assuming it should be possible to do without VBUS sensing, then the present code should be missing some detail. > I would prefer to have a clear understanding of what is causing the issue before making any changes to the patch sent by Jonas in the upstream kernel. Marcelo, can you point where the driver hangs ? One can enable debug messages in the driver by using #define DEBUG_LEVEL DBG_ALL in atmel_usba_udc.h. > > With all that said, I'm not immediately in a position to run tests on my > SAMA5D2 board right now and the kernel on that board is 5.2. I'm not > sure when we we would notice that USB suspend stopped working because > there is no kernel maintenance planned for that board, as far as I know; > someday, however, that work might happen and the lack of working USB > suspend will be a regression in and of itself. > > > I can test it with the AT91SAM9G25 processor and I can also get a SAMA5D27 board to test with. I was able to run the tests on the kernel version pointed by Marcelo (5.10) on SAMA5D2 Xplained and on SAM9x60-EK (the USB IP version on this one should be closer to AT91SAM9G25). It works on both boards with no issues. Both our boards use VBUS sensing. Unfortunately, currently I do not have access to a board with AT91SAM9G25 or to ACME Arietta to check / debug on it. > > > Thanks, > Jonas > > > Best regards, > Marcelo. > Regards, Cristian
