urb->context code cleanup

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

 - If a termios change fails due to lack of memory we should copy the
   old settings back over as the device has not changed
 - Note various locking problems
 - kl5kusb105 had various remaining tty flag handling problems
 - Make safe_serial use tty_insert_flip_string not open coded loops
 - set termios speed properly in usb_serial

Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

__FUNCTION__ is gcc-specific, use __func__

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The usb-serial core no longer checks these fields so remove them from
all of the individual drivers.  They will be removed from the usb-serial
core in a patch later in the series.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Nobody should be using the generic usb-serial for anything other than
testing. Still, it's not a good thing that it's easy to lock up. There
is a traceback from NMI oopser here:
 https://bugzilla.redhat.com/show_bug.cgi?id=431379

But in short, if a line discipline has a chance to echo anything, input
can loop back a write method. So, don't call tty_flip_buffer_push from
under a lock taken on write path.

Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Claim the interface for a USB to serial converter when the tty is open,
and release the interface when the tty is closed.

If a driver doesn't provide a resume function, use the generic resume
instead.

Make sure the generic resume function does not submit the URBs if we're
coming back from autosuspend.  On autoresume, we know that the open
function will be called next, which will attempt to submit the URBs.  If
we submit them in the resume function, the open will fail.

This works for:
 - autosuspend
 - suspending with the tty open or closed
 - hibernate with the tty closed

A hibernate (or a suspend that causes the USB subsystem to lose power)
has issues.  If you have the tty open when you hibernate, a new tty will
be created when the device re-enumerates during resume.

Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

In commit acd2a847e7fee7df11817f67dba75a2802793e5d usb_serial_generic_write()
disables interrupts when taking &port->lock which is also taken in
usb_serial_generic_read_bulk_callback() resulting in an inconsistent lock state
due to the latter not disabling interrupts on the local cpu. Fix that by
disabling interrupts in the latter call site also.

Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: usbserial - fix potential deadlock between write() and IRQ

usb_serial_generic_write() doesn't disable interrupts when taking port->lock,
and could therefore deadlock with usb_serial_generic_read_bulk_callback()
being called from interrupt, taking the same lock. Fix it.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Larry Finger <larry.finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This done in anticipation of removal of urb->status, which will make
that patch easier to review and apply in the future.


Cc: <linux-usb-devel@lists.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

the generic driver also had its own buffering.

Signed-off-by: Oliver Neukum <oneukum@suse.de_
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>