On Sat, 9 Jan 2010, shiraz hashim wrote: > Hello Alan, > > On Fri, Jan 8, 2010 at 8:39 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 8 Jan 2010, shiraz hashim wrote: > > > >> Any help on this. We think to achieve this (configuring endpoints) > >> with above info > >> through ioctl option in the gadget framework. Is it the right approach. > > > > The gadget framework does not include any ioctl options. > > struct usb_gadget_ops defines an ioctl interface, although it used by > no controller driver. I just dont know clearly what is its purpose. At the moment it doesn't have a specific purpose, which is why it's not used. It is there just on general principles. In any case, it isn't well suited to configuring endpoints. > > Why is this necessary? That is, why does the hardware need to know the > > endpoint's config #, interface #, and altsetting #? How does it use > > that information? > > The synopsys designware USB Device handles some of the commands on its > own. It never passes these commands to the application, You mean to the driver? > further it > evaluates these commands ( I dont know why it applies such > intelligence) according to the above mentioned config layout, based > upon which it can even stall that command. > SET INTERFACE is an example. Which requests does the hardware intercept? > I would collect more information on how exactly h/w is using this info > and get back to you. Okay. This seems like a very poor design. If the gadget driver doesn't know when the host has changed an altsetting, how is it supposed to work? If it wanted to define more than one altsetting, each altsetting would have to contain different endpoints! Not that Synopsys is alone in this respect. Other device controllers have similar problems. In the end, I believe it was decided that they could support only one config, one interface, and one altsetting. 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
