1. 18 7月, 2014 1 次提交
  2. 10 7月, 2014 1 次提交
  3. 25 4月, 2014 2 次提交
  4. 19 3月, 2014 1 次提交
  5. 18 3月, 2014 5 次提交
  6. 01 3月, 2014 1 次提交
  7. 14 2月, 2014 1 次提交
  8. 24 12月, 2013 14 次提交
  9. 14 12月, 2013 2 次提交
  10. 12 12月, 2013 1 次提交
  11. 25 10月, 2013 1 次提交
  12. 02 8月, 2013 1 次提交
  13. 01 8月, 2013 1 次提交
  14. 26 6月, 2013 1 次提交
  15. 17 6月, 2013 1 次提交
  16. 16 1月, 2013 3 次提交
  17. 22 11月, 2012 1 次提交
  18. 16 11月, 2012 2 次提交
    • S
      serial: sh-sci: fix possible race cases on SCSCR register accesses · 33b48e16
      Shinya Kuribayashi 提交于
      In the previous commit, console write function (serial_console_write)
      is changed to disable SCI interrupts while printing console strings.
      This introduces possible race cases in the serial startup / shutdown
      functions on SMP systems.
      
      This patch fixes the sh-sci in the same way as commit 9ec1882d
      (tty: serial: imx: console write routing is unsafe on SMP, from
      Xinyu Chen <xinyu.chen@freescale.com>, 2012-08-27) did.
      
      There could be several consumers of the console,
      * the kernel printk
      * the init process using /dev/kmsg to call printk to show log
      * shell, which opens /dev/console and writes with sys_write()
      
      The shell goes into the normal UART open() and write() system calls,
      while the other two go into the console operations.  The open() call
      invokes serial startup function (sci_startup), which will write to
      the SCSCR register (to enable or disable SCI interrupts) without any
      locking.  This will conflict with the console serial function.
      
      Add spinlock protections in sci_startup() and sci_shutdown() properly.
      Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33b48e16
    • S
      serial: sh-sci: add locking to console write function to avoid SMP lockup · 40f70c03
      Shinya Kuribayashi 提交于
      Symptom:
      
      When entering the suspend with Android logcat running, printk() call
      gets stuck and never returns.  The issue can be observed at printk()s
      on nonboot CPUs when going to offline with their interrupts disabled,
      and never seen at boot CPU (core0 in our case).
      
      Details:
      
      serial_console_write() lacks of appropriate spinlock handling.
      
      In SMP systems, as long as sci_transmit_chars() is being processed
      at one CPU core, serial_console_write() can stuck at the other CPU
      core(s), when it tries to access to the same serial port _without_
      a proper locking.  serial_console_write() waits for the transmit FIFO
      getting empty, while sci_transmit_chars() writes data to the FIFO.
      
      In general, peripheral interrupts are routed to boot CPU (core0) by
      Linux ARM standard affinity settings.  SCI(F) interrupts are handled
      by core0, so sci_transmit_chars() is processed on core0 as well.
      
      When logcat is running, it writes enormous log data to the kernel at
      every moment, forever.  So core0 can repeatedly continue to process
      sci_transmit_chars() in its interrupt handler, which eventually makes
      the other CPU core(s) stuck at serial_console_write().
      
      Looking at serial/8250.c, this is a known console write lockup issue
      with SMP kernels.  Fix the sh-sci driver in the same way 8250.c does.
      Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40f70c03