Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 7月, 2014 1 次提交
  3. 25 4月, 2014 2 次提交
  5. 14 2月, 2014 1 次提交
  7. 09 12月, 2013 3 次提交
  9. 17 10月, 2013 1 次提交
  11. 27 9月, 2013 1 次提交
  13. 18 9月, 2013 3 次提交
  15. 15 8月, 2013 1 次提交
  17. 30 7月, 2013 2 次提交
  19. 27 7月, 2013 1 次提交
  21. 26 6月, 2013 1 次提交
  23. 16 3月, 2013 1 次提交
  25. 26 1月, 2013 1 次提交
  27. 21 1月, 2013 2 次提交
    • 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
  29. 16 1月, 2013 3 次提交
  31. 22 11月, 2012 2 次提交
  33. 17 8月, 2012 1 次提交
  35. 27 7月, 2012 4 次提交
  37. 18 7月, 2012 3 次提交
  39. 21 6月, 2012 1 次提交
    • D
      pch_uart: Add eg20t_port lock field, avoid recursive spinlocks · fe89def7
      由 Darren Hart 提交于 
      pch_uart_interrupt() takes priv->port.lock which leads to two recursive
spinlock calls if low_latency==1 or CONFIG_PREEMPT_RT_FULL=y (one
otherwise):

pch_uart_interrupt
  spin_lock_irqsave(priv->port.lock, flags)
  case PCH_UART_IID_RDR_TO (data ready)
  handle_rx_to
    push_rx
      tty_port_tty_get
        spin_lock_irqsave(&port->lock, flags) <--- already hold this lock
        ...
      tty_flip_buffer_push
        ...
        flush_to_ldisc
          spin_lock_irqsave(&tty->buf.lock)
            spin_lock_irqsave(&tty->buf.lock)
            disc->ops->receive_buf(tty, char_buf)
              n_tty_receive_buf
                tty->ops->flush_chars()
                uart_flush_chars
                  uart_start
                    spin_lock_irqsave(&port->lock) <--- already hold this lock

Avoid this by using a dedicated lock to protect the eg20t_port structure
and IO access to its membase. This is more consistent with the 8250
driver.  Ensure priv->lock is always take prior to priv->port.lock when
taken at the same time.

V2: Remove inadvertent whitespace change.
V3: Account for oops_in_progress for the private lock in
    pch_console_write().

Note: Like the 8250 driver, if a printk is introduced anywhere inside
      the pch_console_write() critical section, the kernel will hang
      on a recursive spinlock on the private lock. The oops case is
      handled by using a trylock in the oops_in_progress case.
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
CC: Feng Tang <feng.tang@intel.com>
CC: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe89def7
  41. 19 4月, 2012 1 次提交
    • T
      pch_uart: Fix dma channel unallocated issue · af6d17cd
      由 Tomoya MORINAGA 提交于 
      This driver anticipates pch_uart_verify_port() is not called
during installation.
However, actually pch_uart_verify_port() is called during
installation.
As a result, memory access violation occurs like below.

0. initial value: use_dma=0
1. starup()
    - dma channel is not allocated because use_dma=0
2. pch_uart_verify_port()
    - Set use_dma=1
3. UART processing acts DMA mode because use_dma=1
     - memory access violation occurs!

This patch fixes the issue.

Solution:
Whenever pch_uart_verify_port() is called and then
dma channel is not allocated, the channel should be allocated.
Signed-off-by: NTomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af6d17cd
  43. 10 4月, 2012 4 次提交