lkml.org 
[lkml]   [2014]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RESEND v7 2/2] usb: gadget: f_fs: virtual endpoint address mapping
On Tue, Sep 09, 2014 at 08:02:16AM +0200, Robert Baldyga wrote:
> On 09/08/2014 03:47 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Sep 08, 2014 at 09:57:00AM +0200, Robert Baldyga wrote:
> >> This patch introduces virtual endpoint address mapping. It separates
> >> function logic form physical endpoint addresses making it more hardware
> >> independent.
> >>
> >> Following modifications changes user space API, so to enable them user
> >> have to switch on the FUNCTIONFS_VIRTUAL_ADDR flag in descriptors.
> >>
> >> Endpoints are now refered using virtual endpoint addresses chosen by
> >> user in endpoint descpriptors. This applies to each context when endpoint
> >> address can be used:
> >> - when accessing endpoint files in FunctionFS filesystemi (in file name),
> >> - in setup requests directed to specific endpoint (in wIndex field),
> >> - in descriptors returned by FUNCTIONFS_ENDPOINT_DESC ioctl.
> >>
> >> In endpoint file names the endpoint address number is formatted as
> >> double-digit hexadecimal value ("ep%02x") which has few advantages -
> >> it is easy to parse, allows to easly recognize endpoint direction basing
> >> on its name (IN endpoint number starts with digit 8, and OUT with 0)
> >> which can be useful for debugging purpose, and it makes easier to introduce
> >> further features allowing to use each endpoint number in both directions
> >> to have more endpoints available for function if hardware supports this
> >> (for example we could have ep01 which is endpoint 1 with OUT direction,
> >> and ep81 which is endpoint 1 with IN direction).
> >>
> >> Physical endpoint address can be still obtained using ioctl named
> >> FUNCTIONFS_ENDPOINT_REVMAP, but now it's not neccesary to handle
> >> USB transactions properly.
> >>
> >> Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
> >> Acked-by: Michal Nazarewicz <mina86@mina86.com>
> >
> > after this patch I get build errors:
> >
> > drivers/usb/gadget/function/f_fs.c: In function ‘ffs_epfiles_create’:
> > drivers/usb/gadget/function/f_fs.c:1555:40: error: ‘struct ffs_data’ has no member named ‘eps_addrmap’
> > sprintf(epfiles->name, "ep%02x", ffs->eps_addrmap[i]);
> > ^
> > drivers/usb/gadget/function/f_fs.c: In function ‘ffs_func_setup’:
> > drivers/usb/gadget/function/f_fs.c:2900:19: error: ‘struct ffs_data’ has no member named ‘eps_addrmap’
> > ret = func->ffs->eps_addrmap[ret];
> > ^
> > make[3]: *** [drivers/usb/gadget/function/f_fs.o] Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > make[2]: *** [drivers/usb/gadget/function] Error 2
> > make[1]: *** [drivers/usb/gadget] Error 2
> > make[1]: *** Waiting for unfinished jobs....
> > make: *** [drivers/usb/] Error 2
> >
>
> Array "eps_addrmap" was introduced in patch "usb: gadget: f_fs: fix the
> redundant ep files problem". I have received mails from you and Greg
> that it's already applied to usb tree, so I have assumed that there is
> no need to include it to this patchset. I can resend this patch if it's
> needed.

No, no, I was didn't have -rc4 merged on my next. Now I do.

--
balbi
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2014-09-09 17:21    [W:0.416 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site