Re: Serial-Core: USB-Serial port current issues.

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Wed, Jun 21, 2006 at 01:35:00PM -0300, Luiz Fernando N. Capitulino wrote:
> On Tue, 20 Jun 2006 19:32:33 -0700
> Pete Zaitcev <zaitcev@redhat.com> wrote:
> 
> | On Tue, 20 Jun 2006 16:11:34 -0300, "Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> wrote:
> | 
> | >  Pete, was it your original idea to completely move from the spinlock
> | > to a mutex?
> | 
> | I thought it was the cleanest solution. But perhaps I miss something.
> | I'll look at your reposted patch again, maybe it's all right as it is.
> 
>  Actually, that's the best solution from the USB-Serial's POV.
> 
>  The problem is that several serial drivers uses the uart_port's
> spinlock to implement their own locking, and some of them acquires the
> lock in its interrupt handler...
> 
>  Sh*t.

It all depends what you are locking.

In the uart_update_mctrl() case, the purpose of the locking is to
prevent two concurrent changes to the modem control state resulting
in an inconsistency between the hardware and the software state.  If
it's provable that it is always called from process context (and
it isn't called from a lock_kernel()-section or the lock_kernel()
section doesn't mind a rescheduling point being introduced there),
there's no problem converting that to a mutex.

I suspect that it needed to be a spinlock back in the days when
the low latency mode directly called into the ldisc, which could
then call back into the driver again from interrupt mode.

With get_mctrl(), the situation is slightly more complicated, because
we need to atomically update tty->hw_stopped in some circumstances
(that may also be modified from irq context.)  Therefore, to give
the driver a consistent locking picture, the spinlock is _always_
held.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core