linux-kernel - Re: [PATCH RESEND v7 2/2] usb: gadget: f_fs: virtual endpoint address mapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 09 Sep 2014 08:02:16 +0200
From:	Robert Baldyga <r.baldyga@...sung.com>
To:	balbi@...com
Cc:	gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND v7 2/2] usb: gadget: f_fs: virtual endpoint address
 mapping

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@...sung.com>
>> Acked-by: Michal Nazarewicz <mina86@...a86.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/