* Michal Nazarewicz | 2011-05-20 20:28:59 [+0200]:
>On Fri, 20 May 2011 12:02:59 +0200, Sebastian Andrzej Siewior wrote:
>>+/**
>>+ * struct usb_udc - describes one usb device controller
>>+ * @driver - the gadget driver pointer. For use by the class code
>>+ * @dev - the child device to the actual controller
>>+ * @gadget - the gadget. For use by the class code
>>+ * @list - for use by the udc class driver
>>+ * @name - a human friendly name representation
>>+ *
>>+ * This represents the internal data structure which is used by
>>the UDC-class
>>+ * to hold information about udc driver and gadget together.
>>+ */
>>+struct usb_udc {
>>+ struct usb_gadget_driver *driver;
>>+ struct usb_gadget *gadget;
>>+ struct device dev;
>>+ struct list_head list;
>>+};
>
>So the idea is for all gadgets to use this framework, right? If
>that's the case,
>maybe it's better to just stash those fields inside usb_gadget structure?
>
>Also, isn't it that UDC drivers store pointer to usb_gadget_driver
>internally?
>Because if so, then stashing the above fields inside the usb_gadget_driver
>structure would allow UDC drivers to drop their own internal pointer to
>usb_gadget_driver.
After looking at this, I would prefer it keep it the way it is now and
change it later on.
The udc driver keeps pointer to the gadget driver for ->setup() and other
callbacks. The udc driver also setups a struct device of its own. So
with this udc class we have two of them. The mv_udc driver has a
callback which ensures that the driver is not removed before device's
->release() has been called. This might be the case if someone has a
sysfs file open. This is one of the things which could be moved here.
The struct device in usb_gadget isn't really required. langwell or
dummy_hcd uses it to add a sysfs file the of the current function
driver. Others don't. Moving it to the udc_class would provide the same
functionality accross all gadget drivers.
That means I would like to stash it in a different way:
struct usb_udc {
struct device dev;
struct list_head list;
struct usb_gadget gadget;
};
and struct usb_gadget_driver could be probably accessed from within
"struct usb_gadget". Since every udc can only have one gadget driver.
So that is how I would like change it. Having it organized as I
suggested will make it easier to send small patches and change one thing
at a time. Right now the last patch will be big enough and it will make
"only" usage of this facility in one go (gadget drivers and function
drivers) in order to break bisect.
Sebastian
--
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
