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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <[email protected]> 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)

  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

--
Paul





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux