Re: [PATCH v4 3/4] usb: ffs: check quirk to pad epout buf size when not aligned to maxpacketsize

[Michal Nazarewicz]

On Tue, Nov 05 2013, Alan Stern wrote:
> Maybe Michal can enlighten us.

Sorry for late response, this thread fell under my radar for some
reason.

So here's how it works:

epfile represents an end point file on the fuctionfs file system,
i.e. what user space is seeing.  It's numbering is independent of which
USB configuration is chosen.

A FunctionFS user space daemon may read/write to those files regardless
of whether the function is enabled.  If it is not, the operation will
block until host enables the function.

epfile->ep represents an actual USB end point, and it's number does not
have to correspond to the epfile file name, and may be different in
different configuration.  FunctionFS hides all that from the user space
daemon.

epfile->ep is set when host changes configuration (i.e. function's
set_alt or disable callbacks).  IIRC this implies that epfile->ep cannot
be protected by a mutex, and therefore is protected by a spinlock.

Since it is protected by a spinlock, the ffs_epfile_io function cannot
lock it and then proceed to allocating memory and copying data from user
space.  That's why there is the need for the loop since there is no way
to guarantee that while the memory was allocated and data was read from
user space (if it is a write), the function has not been disabled and
re-enabled.

However, I'm not sure whether maxpacketsize can change.  It is part of
endpoint's descriptor and even though the endpoint number can change
while ffs_epfile_io is running, all the other descriptor fields should
stay the same.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  MichaÅ âmina86â Nazarewicz    (o o)
ooo +--<mpn@xxxxxxxxxx>--<xmpp:mina86@xxxxxxxxxx>--ooO--(_)--Ooo--

Attachment: signature.asc
Description: PGP signature