From: Robert Baldyga <r.baldyga@samsung.com>
To: balbi@ti.com
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND v7 2/2] usb: gadget: f_fs: virtual endpoint address mapping
Date: Tue, 09 Sep 2014 08:02:16 +0200 [thread overview]
Message-ID: <540E97E8.80701@samsung.com> (raw)
In-Reply-To: <20140908134733.GL22409@saruman.home>
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.
next prev parent reply other threads:[~2014-09-09 6:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-08 7:56 [PATCH RESEND v7 0/2] usb: gadget: f_fs: userspace API fixes and improvements Robert Baldyga
2014-09-08 7:56 ` [PATCH RESEND v7 1/2] usb: gadget: f_fs: add ioctl returning ep descriptor Robert Baldyga
2014-09-08 7:57 ` [PATCH RESEND v7 2/2] usb: gadget: f_fs: virtual endpoint address mapping Robert Baldyga
2014-09-08 13:47 ` Felipe Balbi
2014-09-09 6:02 ` Robert Baldyga [this message]
2014-09-09 14:43 ` Felipe Balbi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=540E97E8.80701@samsung.com \
--to=r.baldyga@samsung.com \
--cc=balbi@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.