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

["Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br>]

On Wed, 14 Jun 2006 16:28:09 +0100
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

| On Tue, Jun 13, 2006 at 07:28:29PM -0300, Luiz Fernando N. Capitulino wrote:
| >  I took a look in the Serial Core code and didn't see why set_termios()
| > and break_ctl() (plus tx_empty()) are not allowed to sleep: they doesn't
| > seem to run in atomic context. So, are they allowed to sleep? Isn't the
| > documentation out of date? I've even submitted a patch to fix it [2].
| 
| You are correct - and I will eventually apply your patch.  At the
| moment, I'm throttling back on applying patches so that 2.6.17 can
| finally appear (I don't want to be responsible for Linus saying
| again "too many changes for -final, let's do another -rc".)
| 
| >  For get_mctrl() and set_mctrl() it seems possible to switch from a
| > spinlock to a mutex, as they are not called from an interrupt context.
| > Is this really possible? Would you agree with this change?
| 
| I don't know - that depends whether the throttle/unthrottle driver
| methods are ever called from interrupt context or not.
| 
| What we could do is put a WARN_ON() or might_sleep() in there and
| find out over time if they are called from non-process context.

 Ok, I've put a WARN_ON(in_interrupt()) (as suggested by Greg) in
all the functions which grabs the 'port->lock' spinlock and didn't
get anything with my tests (PPP through a standard modem, serial
console and other simple tests).

 I could submit that debug patch to Andrew, but now I'm wondering
whether the switch is really possible (considering, of course, that
those functions are not called from interrupt context).

 Pete, was it your original idea to completely move from the spinlock
to a mutex?

-- 
Luiz Fernando N. Capitulino