Hi, Gil Weber <gil.we...@servelec-technologies.com> writes: >> interesting. Wonder what Windows is doing differently. Yeah, I guess the >> best way forward is to find which commit caused the regression and git >> bisect is the way to do that. Would be nice to see v3.13, v3.14, >> v3.15... are working or not. The idea is to find the smallest interval >> for bisection. >> > > I finally bisect the kernel (I didn't known that command, thanks for the tip) > and found that it doesn't work anymore from this commit : > > b0bac2581c1918cc4ab0aca01977ad69f0bc127a is the first bad commit > commit b0bac2581c1918cc4ab0aca01977ad69f0bc127a > Author: Robert Baldyga <r.bald...@samsung.com> > Date: Wed Sep 16 12:10:42 2015 +0200 > > usb: gadget: introduce 'enabled' flag in struct usb_ep > > This patch introduces 'enabled' flag in struct usb_ep, and modifies > usb_ep_enable() and usb_ep_disable() functions to encapsulate endpoint > enabled/disabled state. It helps to avoid enabling endpoints which are > already enabled, and disabling endpoints which are already disables. > > From now USB functions don't have to remember current endpoint > enable/disable state, as this state is now handled automatically which > makes this API less bug-prone. > > Signed-off-by: Robert Baldyga <r.bald...@samsung.com> > Signed-off-by: Felipe Balbi <ba...@ti.com> > > > If I comment the test in function usb_ep_enable and usb_ep_disable to avoid > enabling or disabling endpoints that already are, it works. > But I guess the real issue is that this function is called more than once > at some point?
This is the second bug report involving Robert's series, we really need to give some deeper attention to this. Robert, care to comment ? So, this means that if you let endpoints be enabled or disabled more than once, then it works ? Sounds like a bug in the UDC controller to me. Robert's patch just helped trigger the problem. Which controller were you using again ? Was it Atmel UDC ? -- balbi
signature.asc
Description: PGP signature
