Re: [PATCH 1/1, v2] usb-use-kfifo-to-buffer-usb-generic-serial-writes.patch

[Oliver Neukum <oliver@neukum.org>]

Am Freitag, 28. August 2009 22:01:06 schrieb Alan Cox:
> > It seems propagating errors back to user space appears somewhat
> > problematic, but this is true independent of whether a FIFO is used.
>
> The best I can think of would be to implement socket like behaviour from
> networking. That is
>
> - at the start of a write check for an asynchronous error event
> - if there is one, clear the event and report it
> - if not do the normal write
>
> and keep a single 's**t happened' variable to record such matters.

This looks like an excellent suggestion.

> > > user space writes to device
> > > user space waits for answer
> > >
> > > kernel transfers 1. buffer
> > > system suspension - 2. buffer cannot be transfered,
> > > 	as usb_serial_generic_write_start gets -EPERM
> > > system resumption - 2. buffer is never transmitted,
> > > 	user space times out and reports an error
>
> You would need to handle this in the shutdown - and beyond that you need

Why in shutdown?

> to wait for any FIFO in the device before you power it down.

This is not about powering down. If you power down a usb serial
device this will disconnect it unless you implement reset_resume()
which would therefore be another code path.
This problem arises in STR only.

> Its not really fixable as it isn't transactional and you have no idea if
> the state of the other device also changed. Consider
>
> ATD foo
> oops flight time
> suspend
>
> Arrive in Australia
> resume
> ATD foo
>
> Ouch that was an expensive data call...

As soon as you make the next write the buffered data will go out.
So if we don't know the optimal solution, we can still be consistent,
which would be to start IO after resumption in all cases.

	Regards
		Oliver