RE: [PATCH] usb: gadget: composite: Provide list of registered functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Felipe Balbi [mailto:balbi@xxxxxx]
> Sent: Monday, January 19, 2015 7:59 PM
> To: Krzysztof Opasiak
> Cc: balbi@xxxxxx; linux-usb@xxxxxxxxxxxxxxx;
> gregkh@xxxxxxxxxxxxxxxxxxx; bigeasy@xxxxxxxxxxxxx;
> s.wadas@xxxxxxxxxxx; k.lewandowsk@xxxxxxxxxxx;
> m.szyprowski@xxxxxxxxxxx; andrzej.p@xxxxxxxxxxx
> Subject: Re: [PATCH] usb: gadget: composite: Provide list of
> registered functions
> 
> On Mon, Jan 19, 2015 at 02:17:19PM +0100, Krzysztof Opasiak wrote:
> > Driver which provides implementation of some USB functions
> registers
> > usb_function_driver structure in composite framework.
> > Function drivers are identifed using registered name.
> >
> > When gadget is composed using configfs user must know what names
> has
> > been registered. If function is compiled as a module this
> information
> > can be found in modules.alias file. If function is compiled-in,
> there
> > is no way to discover what usb functions are available in
> currently
> > running kernel.
> >
> > Such situation is nothing new for linux kernel.
> > Similar situation is with file systems. While mounting user can
> > provide an fs type argument using -t option in mount.
> > Those type names are registered by drivers. To make those names
> > discoverable there is a /proc/filesystems which exports the list
> of
> > currently registered file systems.
> >
> > This patch adds /proc/usb-functions attribute which exports the
> list
> > of currently registered function drivers.
> > This allows user to discover list of both compiled-in functions
> and
> > from loaded kernel modules.
> >
> > Signed-off-by: Krzysztof Opasiak <k.opasiak@xxxxxxxxxxx>
> 
> you need to document the new file under Documentation/ABI/
> 

I have just sent v2 version with documentation.

I have done some more research and it looks like /sys/kernel
could be a good alternative if you find that proc usage is not
a good idea. What do you thing? Should we continue with
/proc/usb-functions or replace this patch with
/sys/kernel/usb-functions or maybe
/sys/kernel/usb-gadget/usb-functions to have a directory for some
future attributes related to usb gadget?

-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
k.opasiak@xxxxxxxxxxx




--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux