1. 26 1月, 2013 2 次提交
  2. 23 1月, 2013 2 次提交
  3. 22 1月, 2013 5 次提交
  4. 21 1月, 2013 4 次提交
    • L
      pch_uart: add sysrq support · 1f9db092
      Liang Li 提交于
      When send break to the uart port, we always get 'frame error', but we
      can not just reset receive fifo in such case, otherwise the sysrq cmd
      will not be received correctly.
      
      When we handle sysrq output via pch_console_write, the priv lock has
      already been taken so no need to take the lock in pch_console_write.
      Signed-off-by: NLiang Li <liang.li@windriver.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f9db092
    • L
      pch_uart: fix a deadlock when pch_uart as console · 384e301e
      Liang Li 提交于
      When we use pch_uart as system console like 'console=ttyPCH0,115200',
      then 'send break' to it. We'll encounter the deadlock on a cpu/core,
      with interrupts disabled on the core. When we happen to have all irqs
      affinity to cpu0 then the deadlock on cpu0 actually deadlock whole
      system.
      
      In pch_uart_interrupt, we have spin_lock_irqsave(&priv->lock, flags)
      then call pch_uart_err_ir when break is received. Then the call to
      dev_err would actually call to pch_console_write then we'll run into
      another spin_lock(&priv->lock), with interrupts disabled.
      
      So in the call sequence lead by pch_uart_interrupt, we should be
      carefully to call functions that will 'print message to console' only
      in case the uart port is not being used as serial console.
      Signed-off-by: NLiang Li <liang.li@windriver.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      384e301e
    • I
      tty: Correct tty buffer flush. · 64325a3b
      Ilya Zykov 提交于
        The root of problem is carelessly zeroing pointer(in function __tty_buffer_flush()),
      when another thread can use it. It can be cause of "NULL pointer dereference".
        Main idea of the patch, this is never free last (struct tty_buffer) in the active buffer.
      Only flush the data for ldisc(buf->head->read = buf->head->commit).
      At that moment driver can collect(write) data in buffer without conflict.
      It is repeat behavior of flush_to_ldisc(), only without feeding data to ldisc.
      
      Also revert:
        commit c56a00a1
        tty: hold lock across tty buffer finding and buffer filling
      In order to delete the unneeded locks any more.
      Signed-off-by: NIlya Zykov <ilya@ilyx.ru>
      CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64325a3b
    • C
      drivers/tty/serial/8250: use strlcpy instead of strcpy · f8a2b220
      Chen Gang 提交于
        The fields must be null-terminated, or next printk for %s, will cause issue.
      Signed-off-by: NChen Gang <gang.chen@asianux.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8a2b220
  5. 19 1月, 2013 3 次提交
    • J
      tty: Added a CONFIG_TTY option to allow removal of TTY · 4f73bc4d
      Joe Millenbach 提交于
      The option allows you to remove TTY and compile without errors. This
      saves space on systems that won't support TTY interfaces anyway.
      bloat-o-meter output is below.
      
      The bulk of this patch consists of Kconfig changes adding "depends on
      TTY" to various serial devices and similar drivers that require the TTY
      layer.  Ideally, these dependencies would occur on a common intermediate
      symbol such as SERIO, but most drivers "select SERIO" rather than
      "depends on SERIO", and "select" does not respect dependencies.
      
      bloat-o-meter output comparing our previous minimal to new minimal by
      removing TTY.  The list is filtered to not show removed entries with awk
      '$3 != "-"' as the list was very long.
      
      add/remove: 0/226 grow/shrink: 2/14 up/down: 6/-35356 (-35350)
      function                                     old     new   delta
      chr_dev_init                                 166     170      +4
      allow_signal                                  80      82      +2
      static.__warned                              143     142      -1
      disallow_signal                               63      62      -1
      __set_special_pids                            95      94      -1
      unregister_console                           126     121      -5
      start_kernel                                 546     541      -5
      register_console                             593     588      -5
      copy_from_user                                45      40      -5
      sys_setsid                                   128     120      -8
      sys_vhangup                                   32      19     -13
      do_exit                                     1543    1526     -17
      bitmap_zero                                   60      40     -20
      arch_local_irq_save                          137     117     -20
      release_task                                 674     652     -22
      static.spin_unlock_irqrestore                308     260     -48
      Signed-off-by: NJoe Millenbach <jmillenbach@gmail.com>
      Reviewed-by: NJamey Sharp <jamey@minilop.net>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f73bc4d
    • I
      tty: Add driver unthrottle in ioctl(...,TCFLSH,..). · a1bf9584
      Ilya Zykov 提交于
      Regression 'tty: fix "IRQ45: nobody cared"'
      Regression commit 7b292b4b
      
        Function reset_buffer_flags() also invoked during the ioctl(...,TCFLSH,..).
      At the time of request we can have full buffers and throttled driver too.
      If we don't unthrottle driver, we can get forever throttled driver, because,
      after request, we will have empty buffers and throttled driver and
      there is no place to unthrottle driver.
      It simple reproduce with "pty" pair then one side sleep on tty->write_wait,
      and other side do ioctl(...,TCFLSH,..). Then there is no place to do writers wake up.
      Signed-off-by: NIlya Zykov <ilya@ilyx.ru>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1bf9584
    • T
      serial: lpc32xx: Fix fallout from tty_port conversion · 33aeb9da
      Thierry Reding 提交于
      A duplicate definition of the port variable was introduced in the
      interrupt handler, which causes the build to break. The fix is to
      rename the variable to tport, which is already properly used in
      subsequent code.
      Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33aeb9da
  6. 18 1月, 2013 15 次提交
  7. 16 1月, 2013 9 次提交
    • G
      Staging: sb105x: mark it BROKEN · e27a7d79
      Greg Kroah-Hartman 提交于
      It isn't using the port logic, and breaks the build at the moment, so
      mark it BROKEN.
      
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e27a7d79
    • J
      TTY: mn10300-serial, fix build breakage · 59c5f924
      Jiri Slaby 提交于
      By the recent `switch flipping' patches we introduced a build failure
      in the driver:
      mn10300-serial.c:527:19: error: 'port' redeclared as different kind of symbol
      
      I did not notice because I did not even find a compiler for that new
      architecture. Hopefully everything is all right now as I cannot test
      it.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59c5f924
    • J
      TTY: ip22zilog, fix tty_flip_buffer_push call · 2894500d
      Jiri Slaby 提交于
      This one was omitted by the "TTY: switch tty_flip_buffer_push" patch
      because I did not compile-test mips driver. Now I do.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2894500d
    • H
      serial: 8250_dw: Set maxburst size · f5836a55
      Heikki Krogerus 提交于
      The default burst is often 1 byte which is not very optimal.
      The ideal burst size when using 16550A type port would be
      1/2 of fifosize, but this does not work with all Designware
      implementations. Setting it to 1/4 fifosize.
      Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5836a55
    • H
      serial: 8250_dw: Use ifdef with ACPI · 053fac36
      Heikki Krogerus 提交于
      There are no stubs for ACPI functions so the driver needs to
      have this ifdef or it will not compile without ACPI.
      Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      053fac36
    • H
      serial: 8250_dma: TX optimisation · a3b0397f
      Heikki Krogerus 提交于
      Remove one useless wakeup, and do not use DMA with zero byte
      transfers.
      Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3b0397f
    • H
      serial: 8250_dma: Switch to using tty_port · 6f3fe3b1
      Heikki Krogerus 提交于
      The tty buffer functions are converted to using tty_port
      structure instead of struct tty, so we must do the same.
      Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f3fe3b1
    • S
      tty: don't deadlock while flushing workqueue · 852e4a81
      Sebastian Andrzej Siewior 提交于
      Since commit 89c8d91e ("tty: localise the lock") I see a dead lock
      in one of my dummy_hcd + g_nokia test cases. The first run was usually
      okay, the second often resulted in a splat by lockdep and the third was
      usually a dead lock.
      Lockdep complained about tty->hangup_work and tty->legacy_mutex taken
      both ways:
      | ======================================================
      | [ INFO: possible circular locking dependency detected ]
      | 3.7.0-rc6+ #204 Not tainted
      | -------------------------------------------------------
      | kworker/2:1/35 is trying to acquire lock:
      |  (&tty->legacy_mutex){+.+.+.}, at: [<c14051e6>] tty_lock_nested+0x36/0x80
      |
      | but task is already holding lock:
      |  ((&tty->hangup_work)){+.+...}, at: [<c104f6e4>] process_one_work+0x124/0x5e0
      |
      | which lock already depends on the new lock.
      |
      | the existing dependency chain (in reverse order) is:
      |
      | -> #2 ((&tty->hangup_work)){+.+...}:
      |        [<c107fe74>] lock_acquire+0x84/0x190
      |        [<c104d82d>] flush_work+0x3d/0x240
      |        [<c12e6986>] tty_ldisc_flush_works+0x16/0x30
      |        [<c12e7861>] tty_ldisc_release+0x21/0x70
      |        [<c12e0dfc>] tty_release+0x35c/0x470
      |        [<c1105e28>] __fput+0xd8/0x270
      |        [<c1105fcd>] ____fput+0xd/0x10
      |        [<c1051dd9>] task_work_run+0xb9/0xf0
      |        [<c1002a51>] do_notify_resume+0x51/0x80
      |        [<c140550a>] work_notifysig+0x35/0x3b
      |
      | -> #1 (&tty->legacy_mutex/1){+.+...}:
      |        [<c107fe74>] lock_acquire+0x84/0x190
      |        [<c140276c>] mutex_lock_nested+0x6c/0x2f0
      |        [<c14051e6>] tty_lock_nested+0x36/0x80
      |        [<c1405279>] tty_lock_pair+0x29/0x70
      |        [<c12e0bb8>] tty_release+0x118/0x470
      |        [<c1105e28>] __fput+0xd8/0x270
      |        [<c1105fcd>] ____fput+0xd/0x10
      |        [<c1051dd9>] task_work_run+0xb9/0xf0
      |        [<c1002a51>] do_notify_resume+0x51/0x80
      |        [<c140550a>] work_notifysig+0x35/0x3b
      |
      | -> #0 (&tty->legacy_mutex){+.+.+.}:
      |        [<c107f3c9>] __lock_acquire+0x1189/0x16a0
      |        [<c107fe74>] lock_acquire+0x84/0x190
      |        [<c140276c>] mutex_lock_nested+0x6c/0x2f0
      |        [<c14051e6>] tty_lock_nested+0x36/0x80
      |        [<c140523f>] tty_lock+0xf/0x20
      |        [<c12df8e4>] __tty_hangup+0x54/0x410
      |        [<c12dfcb2>] do_tty_hangup+0x12/0x20
      |        [<c104f763>] process_one_work+0x1a3/0x5e0
      |        [<c104fec9>] worker_thread+0x119/0x3a0
      |        [<c1055084>] kthread+0x94/0xa0
      |        [<c140ca37>] ret_from_kernel_thread+0x1b/0x28
      |
      |other info that might help us debug this:
      |
      |Chain exists of:
      |  &tty->legacy_mutex --> &tty->legacy_mutex/1 --> (&tty->hangup_work)
      |
      | Possible unsafe locking scenario:
      |
      |       CPU0                    CPU1
      |       ----                    ----
      |  lock((&tty->hangup_work));
      |                               lock(&tty->legacy_mutex/1);
      |                               lock((&tty->hangup_work));
      |  lock(&tty->legacy_mutex);
      |
      | *** DEADLOCK ***
      
      Before the path mentioned tty_ldisc_release() look like this:
      
      |	tty_ldisc_halt(tty);
      |	tty_ldisc_flush_works(tty);
      |	tty_lock();
      
      As it can be seen, it first flushes the workqueue and then grabs the
      tty_lock. Now we grab the lock first:
      
      |	tty_lock_pair(tty, o_tty);
      |	tty_ldisc_halt(tty);
      |	tty_ldisc_flush_works(tty);
      
      so lockdep's complaint seems valid.
      
      The earlier version of this patch took the ldisc_mutex since the other
      user of tty_ldisc_flush_works() (tty_set_ldisc()) did this.
      Peter Hurley then said that it is should not be requried. Since it
      wasn't done earlier, I dropped this part.
      The code under tty_ldisc_kill() was executed earlier with the tty lock
      taken so it is taken again.
      
      I was able to reproduce the deadlock on v3.8-rc1, this patch fixes the
      problem in my testcase. I didn't notice any problems so far.
      
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      852e4a81
    • H
      serial: 8250_dw: Enable DMA support with ACPI · 7277b2a1
      Heikki Krogerus 提交于
      With ACPI 5.0 we can use the FixedDMA Resource Descriptor to
      extract the needed information for DMA support.
      Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7277b2a1