On Tue, 24 Jan 2012, Michael Hunold wrote: > Hello, > > I have written a USB device controller driver for an ARM-based SoC > called TMPA900 from Toshiba. > > The driver can be found here: > http://git.labs.kernelconcepts.de/?p=topas.git;a=blob;f=drivers/usb/gadget/tmpa9xx-udc.c;h=6d2f5e78393e70286218bee2f73bbb68b4c545aa;hb=HEAD > > I have received a bug report from a user, that is using the serial > gadget with ACM enabled, but that should not matter. > > When he attaches his embedded system to a PC and starts that PC up, the > BIOS tries to find any file storage to boot from. So far, so good. > > The problem is that the BIOS will issue an ep0 setup request but then > the host controller apparently does not collect the answer. I don't see > the specific handling that the device controller usually does when a > setup request is processed. > > Instead the host controller will just issue another ep0 setup request. > My driver does not like that and triggers a BUG(), which is probably too > drastic. > > My question is: what should the device controller do in this case? > > One option is to nuke() the pending ep0 request and just process the new > request. It seems that other drivers are doing this, for example omap_udc.c. That is the right thing to do. > I tried to search for an "official" answer to that question, but had no > luck. > > Any ideas? Cancelling a control transfer in the middle is normal. It will happen, for example, when the host decides that the transfer has taken too long. The device must go along with whatever the host does. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
