[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <53D73B52.1070908@samsung.com>
Date: Tue, 29 Jul 2014 08:12:34 +0200
From: Robert Baldyga <r.baldyga@...sung.com>
To: Michal Nazarewicz <mina86@...a86.com>, balbi@...com
Cc: gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, m.szyprowski@...sung.com,
andrzej.p@...sung.com
Subject: Re: [PATCH v2 1/3] usb: gadget: f_fs: virtual address mapping
On 07/28/2014 05:21 PM, Michal Nazarewicz wrote:
> OK, I see, I misunderstood your change before. So what you're saying is
> that now we have:
> 1. numbers user space provides in bEndpoindAddress,
> 2. physical addresses assigned when endpoint is configured, and
> 3. numbers for file names which go sequentially;
> and what you want is to change the code so that 1 and 3 are the same.
>
> Yes, I agree that would be better, and it was quite an omission on my
> part that I did not implement it that way, but at this point, I would
> argue that breaking backwards compatibility is not really worth it.
Code of examples still works after this changes. We can also assume that
the vast majority of users numbered endpoints sequentially. So there is
very little part of cases when API change can break the function daemon.
Eventually we can add new flag to user descriptors which turns on files
naming convention change (maybe it could be merged with my another patch
https://lkml.org/lkml/2014/7/25/297).
And there is another one change - when endpoint is recipient of setup
request, the physical endpoint address is translated into address chosen
by user in ep descriptor. It also affects on user space API, and
probably should be switched with the user flag.
I can try to move fixes which do not affect on user space API into
separate patch, and then prepare another one, which will add new API
features in case of user flag selection.
--
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/
Powered by blists - more mailing lists