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
