On Wed, 30 Jul 2003, David Brownell wrote:Alan Stern wrote:
There's an ioctl() member of struct usb_gadget_ops, ..
The ioctl() member is for gadget-to-controller requests. If "gadgetfs" gets an ioctl that it doesn't understand, it'll pass that call down to the gadget driver. That doesn't use character devices, it's just a case of "mount -t gadgetfs gadgetfs /dev/gadget".
It sounds like ioctl() is for gadgetfs-to-gadget requests, not gadget-to-controller.
Erm, not so. That particular driver entry is usable by ANY gadget driver (not just gadgetfs) that passes requests from userspace down to the controller. The initial requirement came from a project that was using gadgetfs (and needed some controller-specific functionality), that's all.
On the other hand, it's true that a "struct file_operations" and its methods are specific to a given driver, so the the ep_ioctl() entry for FIFO_FLUSH, FIFO_STATUS, and CLEAR_HALT (all of which map to straight API calls) are specific to the gadgetfs code ... just like its dev_ioctl() entry, which currently just delegates to gadget->ops->ioctl().
That is, an ioctl call provides the gadget driver with a descriptor for a block device or a regular file, which the driver then uses. (Also, that means I can just copy the loop driver code :-)
A module parameter could be even simpler. Eventually those are supposed to show up in sysfs, and there's no confusion about initialization: the parameter is available before the driver binds to the controller. Which is good, since as soon as it successfully binds, the gadget driver must be fully functional...
Doing the same thing via sysfs would come down to having a writeable attribute file where a user process could place a pathname for the device/file. It ought to work just as well, assuming that gadgets are registered in the sysfs file system.
I have a patch, not yet submitted, that makes the gadget controller appear as a sysfs class -- exactly like Greg's "usb_host" class, with the debug files sitting there. It's done for net2280, and likely the pxa2xx_udc will choose the same answer ... though I may first rip out the class support, it doesn't seem useful.
The gadget itself is a child of the controller, just like the root hub is (on the host side). You can certainly assume the gadget will appear in sysfs. But it won't be accessible to the gadget driver until after binding, which means it can't be used for any information that's needed to initialize any device configurations.
It'd be more useful to you maybe if gadget _drivers_ were in sysfs. But that can't be done without a sysfs "bus", it seems.
- Dave
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
