linux-stable.git/drivers/tty/serial/pch_uart.c, branch linux-3.2.y

serial: pch_uart: fix tty-kref leak in dma-rx path

2013-10-26T20:06:05+00:00

commit 19b85cfb190eb9980eaf416bff96aef4159a430e upstream.

Fix tty_kref leak when tty_buffer_request room fails in dma-rx path.

Note that the tty ref isn't really needed anymore, but as the leak has
always been there, fixing it before removing should makes it easier to
backport the fix.

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

serial: pch_uart: fix tty-kref leak in rx-error path

2013-10-26T20:06:05+00:00

commit fc0919c68cb2f75bb1af759315f9d7e2a9443c28 upstream.

Fix tty-kref leak introduced by commit 384e301e ("pch_uart: fix a
deadlock when pch_uart as console") which never put its tty reference.

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

pch_uart: fix a deadlock when pch_uart as console

2013-07-27T04:34:33+00:00

commit 384e301e3519599b000c1a2ecd938b533fc15d85 upstream.

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: Liang Li 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

pch_uart: Add eg20t_port lock field, avoid recursive spinlocks

2012-10-10T02:31:12+00:00

commit 2588aba002d14e938c2f56d299ecf3e7ce1302a5 upstream.

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: Darren Hart 
CC: Tomoya MORINAGA 
CC: Feng Tang 
CC: Alexander Stein 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2:
 - Adjust context
 - Drop changes to pch_console_write()]
Signed-off-by: Ben Hutchings

pch_uart: Fix parity setting issue

2012-08-09T23:25:19+00:00

commit 38bd2a1ac736901d1cf4971c78ef952ba92ef78b upstream.

Parity Setting value is reverse.
E.G. In case of setting ODD parity, EVEN value is set.
This patch inverts "if" condition.

Signed-off-by: Tomoya MORINAGA 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

pch_uart: Fix rx error interrupt setting issue

2012-08-09T23:25:18+00:00

commit 9539dfb7ac1c84522fe1f79bb7dac2990f3de44a upstream.

Rx Error interrupt(E.G. parity error) is not enabled.
So, when parity error occurs, error interrupt is not occurred.
As a result, the received data is not dropped.

This patch adds enable/disable rx error interrupt code.

Signed-off-by: Tomoya MORINAGA 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 
[Backported by Tomoya MORINGA: adjusted context]
Signed-off-by: Ben Hutchings

pch_uart: Fix missing break for 16 byte fifo

2012-08-09T23:25:17+00:00

commit 9bc03743fff0770dc5a5324ba92e67cc377f16ca upstream.

Otherwise we fall back to the wrong value.

Reported-by: 
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44091
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

pch_uart: Fix dma channel unallocated issue

2012-05-11T12:14:00+00:00

commit af6d17cdc8c89aeb3101f0d27cd32fc0592b40b2 upstream.

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: Tomoya MORINAGA 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

pch_uart: Fix MSI setting issue

2012-04-22T22:31:01+00:00

commit 867c902e07d5677e2a5b54c0435e589513abde48 upstream.

The following patch (MSI setting) is not enough.

commit e463595fd9c752fa4bf06b47df93ef9ade3c7cf0
Author: Alexander Stein 
Date:   Mon Jul 4 08:58:31 2011 +0200

    pch_uart: Add MSI support

    Signed-off-by: Alexander Stein 
    Signed-off-by: Greg Kroah-Hartman 

To enable MSI mode, PCI bus-mastering must be enabled.
This patch enables the setting.

cc: Alexander Stein 
Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Greg Kroah-Hartman

pch_uart: Fix DMA resource leak issue

2011-11-15T20:13:43+00:00

Changing UART mode PIO->DMA->PIO->DMA like below, pch_uart driver can't get
DMA channel resource.

setserial /dev/ttyPCH0 ^low_latency
setserial /dev/ttyPCH0 low_latency

CAUSE:
Changing mode using setserial command, ".startup" function which gets DMA
channel is called before ".verify_port" function which sets
dma-flag(use_dma/use_dma_flag) as 1.

PIO->DMA
  .startup: Since dma-flag is 0, DMA channel is not requested.
  .verify_port: dma-flag is set as 1.
  .shutdown: N/A

DMA->PIO
  .startup: Since dma-flag is 1, DMA channel is requested.
  .verify_port: dma-flag is set as 0.
  .shutdown: Since dma-flag is 0, DMA channel is not released.

This means DMA channel resource leak occurs.
Next time, this driver can't get DMA channel resource forever.

MODIFICATION:
  Currently, when release DMA channel resource, this driver checks dma-flag.
  However, this specification occurs the above issue.
  This driver must check whether dma_request_channel is executed or not.
  The values are saved in private data variable "chan_tx/chan_tx".
  These variables mean if the value is NULL, DMA channel is not requested,
  if not NULL, DMA channel is requested.

This patch fixes the issue.

Signed-off-by: Tomoya MORINAGA 
Acked-by: Alan Cox 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman