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 <[EMAIL PROTECTED]> wrote: > > | On Tue, 20 Jun 2006 16:11:34 -0300, "Luiz Fernando N. Capitulino" <[EMAIL > PROTECTED]> 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
