Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 20 4月, 2011 1 次提交
  3. 18 2月, 2011 1 次提交
  5. 14 1月, 2011 1 次提交
    • G
      tty: move drivers/serial/ to drivers/tty/serial/ · ab4382d2
      由 Greg Kroah-Hartman 提交于 
      The serial drivers are really just tty drivers, so move them to
drivers/tty/ to make things a bit neater overall.

This is part of the tty/serial driver movement proceedure as proposed by
Arnd Bergmann and approved by everyone involved a number of months ago.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rogier Wolff <R.E.Wolff@bitwizard.nl>
Cc: Michael H. Warfield <mhw@wittsend.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ab4382d2
  7. 11 8月, 2010 1 次提交
  9. 27 7月, 2010 1 次提交
  11. 04 5月, 2010 1 次提交
  13. 03 3月, 2010 1 次提交
  15. 29 10月, 2009 1 次提交
  17. 20 9月, 2009 2 次提交
  19. 30 7月, 2009 1 次提交
  21. 17 6月, 2009 1 次提交
  23. 01 4月, 2009 1 次提交
  25. 19 2月, 2009 1 次提交
    • A
      atmel_serial might lose modem status change · 27c0c8e5
      由 Atsushi Nemoto 提交于 
      I found a problem of handling of modem status of atmel_serial driver.

With the commit 1ecc26 ("atmel_serial: split the interrupt handler"),
handling of modem status signal was splitted into two parts.  The
atmel_tasklet_func() compares new status with irq_status_prev, but
irq_status_prev is not correct if signal status was changed while the port
is closed.

Here is a sequence to cause problem:

1. Remote side sets CTS (and DSR).
2. Local side close the port.
3. Local side clears RTS and DTR.
4. Remote side clears CTS and DSR.
5. Local side reopen the port.  hw_stopped becomes 1.
6. Local side sets RTS and DTR.
7. Remote side sets CTS and DSR.

Then CTS change interrupt can be received, but since CTS bit in
irq_status_prev and new status is same, uart_handle_cts_change() will not
be called (so hw_stopped will not be cleared, i.e.  cannot send any data).

I suppose irq_status_prev should be initialized at somewhere in open
sequence.

Itai Levi pointed out that we need to initialize atmel_port->irq_status
as well here. His analysis is as follows:

> Regarding the second part of the patch (which resets irq_status_prev),
> it turns out that both versions of the patch (mine and Atsushi's)
> still leave enough room for faulty behavior when opening the port.
>
> This is because we are not resetting both irq_status_prev and
> irq_status in atmel_startup() to CSR, which leads faulty behavior in
> the following sequences:
>
> First case:
> 1. closing the port while CTS line = 1 (TX not allowed)
> 2. setting CTS line = 0 (TX allowed)
> 3. opening the port
> 4. transmitting one char
> 5. Cannot transmit more chars, although CTS line is 0
>
> Second case:
> 1. closing the port while CTS line = 0 (TX allowed)
> 2. setting CTS line = 1 (TX not allowed)
> 3. opening the port
> 4. receiving some chars
> 5. Now we can transmit, although CTS line is 1
>
> This reason for this is that the tasklet is scheduled as a result of
> TX or RX interrupts (not a status change!), in steps 4 above. Inside
> the tasklet, the atmel_port->irq_status (which holds the value from
> the previous session) is compared to atmel_port->irq_status_prev.
> Hence, a status-change of the CTS line is faultily detected.
>
> Both cases were verified on 9260 hardware.

[haavard.skinnemoen@atmel.com: folded with patch from Itai Levi]
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: Remy Bohmer <linux@bohmer.net>
Cc: Marc Pignat <marc.pignat@hevs.ch>
Cc: Itai Levi <itai.levi.devel@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      27c0c8e5
  27. 16 1月, 2009 1 次提交
  29. 07 11月, 2008 1 次提交
  31. 23 9月, 2008 1 次提交
  33. 07 8月, 2008 1 次提交
  35. 21 7月, 2008 2 次提交
  37. 02 7月, 2008 2 次提交
  39. 07 6月, 2008 1 次提交
  41. 28 4月, 2008 1 次提交
  43. 16 4月, 2008 1 次提交
  45. 03 4月, 2008 2 次提交
  47. 24 2月, 2008 1 次提交
  49. 09 2月, 2008 9 次提交
  51. 04 2月, 2008 1 次提交
  53. 15 11月, 2007 1 次提交
  55. 17 7月, 2007 1 次提交
    • H
      atmel_serial: fix break handling · 9e6077bd
      由 Haavard Skinnemoen 提交于 
      The RXBRK field in the AT91/AT32 USART status register has the
following definition according to e.g. the AT32AP7000 data sheet:

    RXBRK: Break Received/End of Break
    0: No Break received or End of Break detected since the last RSTSTA.
    1: Break Received or End of Break detected since the last RSTSTA.

Thus, for each break, the USART sets the RXBRK bit twice. This patch
modifies the driver to report the break event to the serial core only
once by keeping track of whether a break condition is currently
active. The break_active flag is reset as soon as a character is
received, so even if we miss the start-of-break interrupt this should
do the right thing.
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Andrew Victor <andrew@sanpeople.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ivan Kuten <ivan.kuten@promwad.com>
Cc: Nicolas Ferre <nicolas.ferre@rfo.atmel.com>
Cc: Patrice Vilchez <patrice.vilchez@rfo.atmel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9e6077bd