On Sat, 17 Apr 2010, Sumit Panchasara wrote: > On 04/16/2010 08:13 PM, Alan Stern wrote: > > > > Which tests fail, and why? Can you provide the USB20CV test log? > > > > Alan Stern > > > > > > > > > All tests starting from set interface fails. > > I am not sure what is happening here but if I issue same clr_halt > request on source/sink eps from gadget driver (mv_udc.ko) by capturing Is mv_udc a gadget driver or a device controller driver? > set_interface request then it passes (i.e. without delegating to upper > layers). Here the set interface is happens for interface 0, alt setting 0. > > If I delegate it to gadgetfs.ko and subsequently reaches to user space > usb.c which when issues clr_hlt via ioctl and that when comes to > mv_udc.ko module, it fails and stall the eps. Thus all subsequent tests > fails as well. If mv_udc were a gadget driver then it couldn't be loaded at the same time as gadgetfs. Hence it must be a device controller driver. I'm not sure I understand what you're saying. usb.c issues an ioctl to do a Clear-Halt, and the Clear-Halt request is passed to mv_udc, and the Clear-Halt fails, and as a result the endpoint gets halted. Is that right? In other words, the Clear-Halt request ends up doing the opposite of what it's supposed to do. If that's what you mean, it indicates there's a bug in mv_udc. > I captured all parameters which comes from user space with clr_halt > request but those looks valid so I am not able to make out what is > happening wrong when user space (usb.c) issues clr_halt request on > source/sink fds...? You need to look at what happens inside mv_udc. Why does the Clear-Halt request fail? > I believe it is unacceptable to not delegate set_interface request to > upper layers of gadget drivers. Again I don't understand. Gadget drivers don't have upper and lower layers. For example, look at zero.c -- it only has one layer. Do you mean to say it is unacceptable for device controller drivers not to delegate Set-Interface requests to gadget drivers? Then I agree -- and almost all device controller drivers _do_ delegate these requests. (The delegation doesn't happen only in cases where the Set-Interface is handled directly by the hardware and the device controller driver isn't aware of it.) Or maybe you mean to say it is unacceptable for gadget drivers not to delegate Set-Interface requests to the device controller driver. This makes no sense -- the gadget driver _must_ do much of the work for handling Set-Interface. That work cannot be delegated. 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
