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
* 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 thi
Szyprowski; 'Greg Kroah-Hartman';
> ba...@ti.com; 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 th
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
'; 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
>
> On 2014-10-17 16:30:24 [+0200], Krzysztof Opasiak wrote:
> > > So you
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 prob
Pietrasiewicz; Marek Szyprowski; 'Greg Kroah-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
>
>
>
an Andrzej Siewior;
> matt.por...@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 ab
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 wh
17 lip 2014 09:13 "Andrzej Pietrasiewicz" 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:
>
>
>
>
>>> Since target and its userland tool (targ
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:
Since target and its userland tool (targetcli) is available for
sometime now, maybe a look on those will give an idea
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
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 a
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 available.
Knowing what functions there are is not the same
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 l
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.
failu
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
gt; Sebastian Andrzej Siewior; 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)
> {
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
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
20 matches
Mail list logo
