[V6,1/3] USB: serial: f81232: clear overrun flag

[Johan Hovold <johan@kernel.org>]

On Wed, Apr 03, 2019 at 04:40:30PM +0800, Ji-Ze Hong (Peter Hong) wrote:
> The F81232 will report data and LSR with bulk like following format:
> bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]...
> 
> LSR will auto clear frame/parity/break error flag when reading by H/W,
> but overrrun will only cleared when reading LSR. So this patch add a
> worker to read LSR when overrun and flush the worker on close() &
> suspend().
> 
> Cc: Oliver Neukum <oneukum@suse.com>
> Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
> ---
> V6:
> 	1: Add deferred_lsr_work_needed to re-trigger when f81232_resume()
> 
> v5:
> 	1: Source code base revert to v3 and remove all v4 changes.
> 	2: Add serial->suspending check in f81232_process_read_urb()
> 	   before schedule_work(&priv->lsr_work) to avoid race condition.
> 
> v4:
> 	1: Add serial->suspending check in f81232_lsr_worker() to avoid
> 	   re-trigger
> 	2: Add port_priv-lsr_work_resched to re-trigger LSR worker
> 
> v3:
> 	1: Add flush_work(&port_priv->lsr_work) in f81232_suspend().
> 
> v2:
> 	1: Add flush_work(&port_priv->lsr_work) in f81232_close().
> 
>  drivers/usb/serial/f81232.c | 55 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 55 insertions(+)

> +static int f81232_suspend(struct usb_serial *serial, pm_message_t message)
> +{
> +	struct f81232_private *port_priv;
> +
> +	port_priv = usb_get_serial_port_data(serial->port[0]);
> +	flush_work(&port_priv->lsr_work);

Note that usb-serial core doesn't manage the interrupt urb for you, so
there's already a bug in this driver which should be fixed in a
preparatory patch (i.e. resubmit the interrupt urb on resume).

And if you stop the bulk-in and interrupt urbs explicitly here, you can
safely flush the lsr work without any races afterwards.

Also note that the interrupt work is currently never flushed on suspend
or close either... Another thing to fix first.

There's also a layering violation here, since you're accessing the child
port data from a parent interface driver callback. The port driver could
have been unbound and you'd get a NULL deref here. Iterating over the
interface's ports, and checking if it's been opened (as you need to do
on resume anyway) might be enough though.

Johan