Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

["Michał Nazarewicz" <m.nazarewicz-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>]

> On Mon, Apr 19, 2010 at 08:57:18PM +0200, ext Michał Nazarewicz wrote:
>> on top of FunctionFS before optimising the code) and in particular u_char
>> seem to be a good piece to steal code from. ;)  Still, as said, I haven't
>> analysed possible optimisations just yet.

On Mon, 19 Apr 2010 22:04:57 +0200, Felipe Balbi <felipe.balbi-xNZwKgViW5g@public.gmane.orgm> wrote:
> go for it :-)

I only started wondering whether buffering won't break some drivers.
Queuing the requests and buffering the data may be good from speed
point of view, but it may lead to user space driver loosing control
over the transmission.

My understanding of USB protocol is not perfect so I may use wrong
terms here, but please bare with me.

fsync() solves the issue of not knowing when the data is sent but
there is no similar mechanism for reading.

In particular how can we stall on read? Say protocol is designed in
such a way, that host sends a request on EP0 and some data on EP1.
Now, after handling the control request from EP0 we would like to
stall no EP1 but by the time we try to do that the data from host
has already been received and buffered in FunctionFS.

-- 
Best regards,                                           _     _
  .o. | Liege of Serenely Enlightened Majesty of       o' \,=./ `o
  ..o | Computer Science,  Michał "mina86" Nazarewicz     (o o)
  ooo +---[mina86-deATy8a+UHjQT0dZR+AlfA@public.gmane.org]---[mina86-/eSpBmjxGS4dnm+yROfE0A@public.gmane.org]---ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html