On Thu, 16 Jun 2011, Alan Stern wrote: > On Thu, 16 Jun 2011, Felipe Balbi wrote: > > > Hi, > > > > On Thu, Jun 16, 2011 at 11:06:47AM -0400, Alan Stern wrote: > > > On Thu, 16 Jun 2011, Tatyana Brokhman wrote: > > > > > > > This implementation adds a new proprietary device control requests (to be > > > > handled by the dummy_hcd) that initiates a connect/disconnect sequence. > > > > The bRequest value of the new control request is 0x52. > > > > It is used by the user-space Unit testing application. > > > > > > This is not a bad idea. On the other hand, it is slightly peculiar -- > > > it you're testing with real UDC hardware, you would do the > > > disconnect/reconnect sequence by hand (unplug and replug the USB > > > cable), not in software. > > > > actually, this is quite useful. Specially for the controllers which > > _can_ do soft-connect by toggling data pullups. I would rather have > > these sort of thing maybe in composite.c, so that we can build tests > > with all gadget drivers/controllers, not only dummy_hcd. > > It sounds like you don't understand the point of this patch. It allows > the _host_ to control the pullup settings. Sorry, the misunderstanding was mine -- I didn't grasp what you were suggesting. Yes, something like this could be useful in composite.c. It could be defined as a vendor-specific request with the device as the recipient. One problem with making it special for dummy-hcd is that it would prevent people from testing gadget drivers that want to use the same bRequest value to mean something different. Putting it in composite.c would force all function drivers to know about it. 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
