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

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

 Hi Paul,

On Mon, 26 Jun 2006 19:49:09 -0500
Paul Fulghum <paulkf@microgate.com> wrote:

| On Mon, 2006-06-26 at 15:26 -0700, Greg KH wrote:
| > On Fri, Jun 23, 2006 at 02:28:42PM -0300, Luiz Fernando N. Capitulino wrote:
| > > On Thu, 22 Jun 2006 09:29:40 +0100
| > > Russell King <rmk+lkml@arm.linux.org.uk> wrote:
| > > 
| > > | 
| > > | Consider this scenario with what you're proposing:
| > > | 
| > > | 	thread				irq
| > > | 
| > > | 	take mutex
| > > | 	get_mctrl
| > > | 					cts changes state
| > > | 					take port lock
| > > | 					mctrl state read
| > > | 					tty->hw_stopped changed state
| > > | 					release port lock
| > > | 	releaes mutex
| > > | 	take port lock
| > > | 	update tty->hw_stopped
| > > | 	release port lock
| > > | 
| > > | Now, tty->hw_stopped does not reflect the hardware state, which will be
| > > | buggy and can cause a loss of transmission.
| > > | 
| > > | I'm not sure what to suggest on this one since for USB drivers you do
| > > | need to be able to sleep in this method... but for UARTs you must not.
| 
| What about this ugly fragment?
| (assuming get_mctrl not called from IRQ)

 What's the problem with get_mctrl() being called from IRQ?

 Note that get_mctrl() is a callback and the driver is free to call _its_
get_mctrl() from IRQ if it wants to.

|   take mutex
|   take port lock
| again:
|   save local copy of icount
|   release port lock
|   get_mctrl
|   take port lock
|   if (icount changed)
|     goto again
|   update tty->hw_stopped
|   release port lock
|   release mutex

 Well, I think it'd work. But how can we keep track of 'icount'?
Should the driver add 1 if it updates 'tty->hw_stopped'?

PS: Sorry for the long delay, I was off last week.

-- 
Luiz Fernando N. Capitulino