* Krzysztof Opasiak | 2014-10-27 11:53:09 [+0100]:
Main difference is that each loaded fabric module provides its own
directory (/sys/kernel/config/target/$FABRIC_MOD/). This means that
each loaded or built-in module has there it own directory.
So I assumed they don't do and I don't recall this
On Wed, Nov 05, 2014 at 11:18:12PM +0100, Sebastian Andrzej Siewior wrote:
* Krzysztof Opasiak | 2014-10-27 11:53:09 [+0100]:
Main difference is that each loaded fabric module provides its own
directory (/sys/kernel/config/target/$FABRIC_MOD/). This means that
each loaded or built-in module
; matt.por...@linaro.org; linux-usb@vger.kernel.org
Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of
available functions
On 2014-10-21 11:53:38 [+0200], Krzysztof Opasiak wrote:
I don't know the target and it's configfs usage so I can only
speak
about composing gadget. Assuming
On 2014-10-21 11:53:38 [+0200], Krzysztof Opasiak wrote:
I don't know the target and it's configfs usage so I can only speak
about composing gadget. Assuming that all usb functions are available
And thatis why I told you to look at it instead re-inventing the wheel.
in kernel is not a good
';
matt.por...@linaro.org; linux-usb@vger.kernel.org
Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of
available functions
On 2014-10-17 16:30:24 [+0200], Krzysztof Opasiak wrote:
So you didn't answer my questions. Say you have a list of two
functions
says acm and ncm. Based
On 2014-10-17 16:30:24 [+0200], Krzysztof Opasiak wrote:
So you didn't answer my questions. Say you have a list of two
functions
says acm and ncm. Based on this information how do you know how to
configure it?
That's a good question but not directly related to current problem.
The
On 2014-07-17 10:32:36 [+0200], Krzysztof Opasiak wrote:
In my opinion the target client is not libusbg but a layer above it,
let's call it gadget tool and gadget daemon. Libusbg should provide
convenient API for all functions which has been merged to kernel.
Library doesn't need to know which
...@linaro.org; linux-usb@vger.kernel.org
Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of
available functions
On 2014-07-17 10:32:36 [+0200], Krzysztof Opasiak wrote:
In my opinion the target client is not libusbg but a layer above
it,
let's call it gadget tool and gadget
-Hartman';
ba...@ti.com; 'Sebastian Andrzej Siewior'; matt.por...@linaro.org;
linux-usb@vger.kernel.org
Subject: RE: [PATCHv2] usb: gadget: composite: Provide a list of
available functions
-Original Message-
From: Sebastian Andrzej Siewior [mailto:bige...@breakpoint.cc]
Sent
W dniu 16.07.2014 16:45, Felipe Balbi pisze:
On Wed, Jul 16, 2014 at 09:58:31AM +0200, Sebastian Andrzej Siewior wrote:
On 07/14/2014 12:36 PM, Andrzej Pietrasiewicz wrote:
snip
Since target and its userland tool (targetcli) is available for
sometime now, maybe a look on those will give an
17 lip 2014 09:13 Andrzej Pietrasiewicz andrze...@samsung.com napisał(a):
W dniu 16.07.2014 16:45, Felipe Balbi pisze:
On Wed, Jul 16, 2014 at 09:58:31AM +0200, Sebastian Andrzej Siewior wrote:
On 07/14/2014 12:36 PM, Andrzej Pietrasiewicz wrote:
snip
Since target and its userland tool
On 07/14/2014 12:36 PM, Andrzej Pietrasiewicz wrote:
W dniu 14.07.2014 11:50, Sebastian Andrzej Siewior pisze:
On 07/14/2014 11:35 AM, Andrzej Pietrasiewicz wrote:
A userland tool for assembling gadgets with configfs needs to know what
it can or cannot do, that is, what usb functions are
On Wed, Jul 16, 2014 at 09:58:31AM +0200, Sebastian Andrzej Siewior wrote:
On 07/14/2014 12:36 PM, Andrzej Pietrasiewicz wrote:
W dniu 14.07.2014 11:50, Sebastian Andrzej Siewior pisze:
On 07/14/2014 11:35 AM, Andrzej Pietrasiewicz wrote:
A userland tool for assembling gadgets with configfs
W dniu 11.07.2014 15:22, Sebastian Andrzej Siewior pisze:
On 07/10/2014 04:17 PM, Krzysztof Opasiak wrote:
another class ? Please don't, we already have the udc class, we
could find a way to just use that instead.
Using udc clas is not a good idea. This may cause failures in userspace.
On 07/14/2014 11:35 AM, Andrzej Pietrasiewicz wrote:
A userland tool for assembling gadgets with configfs needs to know what
it can or cannot do, that is, what usb functions are available.
Knowing what functions there are is not the same thing as being able
to discover it, so in fact this
On 07/10/2014 04:17 PM, Krzysztof Opasiak wrote:
another class ? Please don't, we already have the udc class, we
could find a way to just use that instead.
Using udc clas is not a good idea. This may cause failures in userspace.
failures? like what?
How would you like to tell that this is
When gadgets are composed with configfs the user must know what are the
available function names. The names are parts of usb_f_*.ko
modules' aliases. If a function is compiled as a module, the information
can be found in modules.alias file. But if a function is compiled-in,
there is no way to know
On Thu, Jul 10, 2014 at 12:30:59PM +0200, Andrzej Pietrasiewicz wrote:
When gadgets are composed with configfs the user must know what are the
available function names. The names are parts of usb_f_*.ko
modules' aliases. If a function is compiled as a module, the information
can be found in
; Marek Szyprowski
Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of
available functions
(...)
+static ssize_t gadget_func_list_show(struct class *c,
+struct class_attribute *a, char
*buf)
{
+ return usb_function_list_functions(buf, PAGE_SIZE
19 matches
Mail list logo
