On Thursday, November 22, 2012 3:55 PM Sebastian Andrzej Siewior wrote:
> * Andrzej Pietrasiewicz | 2012-11-22 13:06:55 [+0100]:
>
<snip>
> >diff --git a/include/linux/usb/composite.h
> b/include/linux/usb/composite.h
> >index e84c754..5bac1f8 100644
> >--- a/include/linux/usb/composite.h
> >+++ b/include/linux/usb/composite.h
> >@@ -39,6 +39,7 @@
> > #include <linux/usb/ch9.h>
> > #include <linux/usb/gadget.h>
> > #include <linux/log2.h>
> >+#include <linux/configfs.h>
> >
> > /*
> > * USB function drivers should return USB_GADGET_DELAYED_STATUS if they
> >@@ -146,6 +147,11 @@ struct usb_function {
> > * we can't restructure things to avoid mismatching.
> > * Related: unbind() may kfree() but bind() won't...
> > */
> >+
> >+ struct config_group *(*make_group)(struct config_group *parent,
> >+ const char *name);
> >+ int (*add_function)(struct usb_configuration *c, struct usb_function
> *f,
> >+ struct config_item *item, void *data);
>
> a wrapper? I though you pass the configfs root node and the function
> will add all files / subdirectories. Why do we have two callbacks?
>
make_group explanation:
In configfs the directory needs to know how to create its subdirectories.
In order to do it there are make_group and make_item methods in
struct configfs_group_operations (make_group and make_item are mutually
exclusive, i.e. only one of them can be specified). In the following
UFG implementation the function-dependent directories subtree is
rooted at some configfs directory which is of a generic type. So there
needs to be a way to pass this function-specific method to the generic
code. make_group here serves this purpose. It is used during gadget
setup, that is, when the configfs directories are created but prior
to actual binding of the gadget. Since creating the directories
does not equal gadget binding, it needs to be a separate function.
add_function explanation:
In order to use your framework for registering the usb functions,
the usb_get_function should be called from the generic code (otherwise
it leads to a situation where one needs to have a function's module
loaded in order to request this module... not good :O ). Once the
generic code has the function, it can call usb_add_funciton.
But some functions (as is the case with mass storage)
seem to need some additional function-specific activities together
with usb_add_function. So I decided to collect them in one
add_function operation with the semantics: do usb_add_function
plus any necessary function-specific things related to adding
this function.
Andrzej
--
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
