linux-toradex.git/drivers/tty, branch v3.18.16

tty/n_gsm.c: fix a memory leak when gsmtty is removed

2015-06-10T17:42:22+00:00

[ Upstream commit 8f9cfeed3eae86c70d3b04445a6f2036b27b6304 ]

when gsmtty_remove put dlci, it will cause memory leak if dlci->port's refcount is zero.
So we do the cleanup work in .cleanup callback instead.

dlci will be last put in two call chains.
1) gsmld_close -> gsm_cleanup_mux -> gsm_dlci_release -> dlci_put
2) gsmld_remove -> dlci_put
so there is a race. the memory leak depends on the race.

In call chain 2. we hit the memory leak. below comment tells.

release_tty -> tty_driver_remove_tty -> gsmtty_remove -> dlci_put -> tty_port_destructor (WARN_ON(port->itty) and return directly)
                         |
                tty->port->itty = NULL;
                         |
                tty_kref_put ---> release_one_tty -> gsmtty_cleanup (added by our patch)

So our patch fix the memory leak by doing the cleanup work after tty core did.

Signed-off-by: Pan Xinhui 
Fixes: dfabf7ffa30585
Cc: stable  # 3.14+
Acked-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xen/events: don't bind non-percpu VIRQs with percpu chip

2015-06-09T17:43:54+00:00

[ Upstream commit 77bb3dfdc0d554befad58fdefbc41be5bc3ed38a ]

A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different
VCPU than it is bound to.  This can result in a race between
handle_percpu_irq() and removing the action in __free_irq() because
handle_percpu_irq() does not take desc->lock.  The interrupt handler
sees a NULL action and oopses.

Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER).

  # cat /proc/interrupts | grep virq
   40:      87246          0  xen-percpu-virq      timer0
   44:          0          0  xen-percpu-virq      debug0
   47:          0      20995  xen-percpu-virq      timer1
   51:          0          0  xen-percpu-virq      debug1
   69:          0          0   xen-dyn-virq      xen-pcpu
   74:          0          0   xen-dyn-virq      mce
   75:         29          0   xen-dyn-virq      hvc_console

Signed-off-by: David Vrabel 
Cc: 
Signed-off-by: Sasha Levin

xen/console: Update console event channel on resume

2015-05-23T19:53:06+00:00

[ Upstream commit b9d934f27c91b878c4b2e64299d6e419a4022f8d ]

After a resume the hypervisor/tools may change console event
channel number. We should re-query it.

Signed-off-by: Boris Ostrovsky 
Cc: 
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

tty/serial: at91: maxburst was missing for dma transfers

2015-05-17T23:12:40+00:00

[ Upstream commit a8d4e01637902311c5643b69a5c80e2805f04054 ]

Maxburst was not set when doing the dma slave configuration. This value
is checked by the recently introduced xdmac. It causes an error when
doing the slave configuration and so prevents from using dma.

Signed-off-by: Ludovic Desroches 
Cc:  # 3.12 and later
Acked-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: xilinx: Use platform_get_irq to get irq description structure

2015-05-17T23:12:38+00:00

[ Upstream commit 5c90c07b98c02198d9777a7c4f3047b0a94bf7ed ]

For systems with CONFIG_SERIAL_OF_PLATFORM=y and device_type =
"serial"; property in DT of_serial.c driver maps and unmaps IRQ (because
driver probe fails). Then a driver is called but irq mapping is not
created that's why driver is failing again in again on request_irq().
Based on this use platform_get_irq() instead of platform_get_resource()
which is doing irq_desc allocation and driver itself can request IRQ.

Fix both xilinx serial drivers in the tree.

Signed-off-by: Michal Simek 
CC: 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: of-serial: Remove device_type = "serial" registration

2015-05-17T23:12:37+00:00

[ Upstream commit 6befa9d883385c580369a2cc9e53fbf329771f6d ]

Do not probe all serial drivers by of_serial.c which are using
device_type = "serial"; property. Only drivers which have valid
compatible strings listed in the driver should be probed.

When PORT_UNKNOWN is setup probe will fail anyway.

Arnd quotation about driver historical background:
"when I wrote that driver initially, the idea was that it would
get used as a stub to hook up all other serial drivers but after
that, the common code learned to create platform devices from DT"

This patch fix the problem with on the system with xilinx_uartps and
16550a where of_serial failed to register for xilinx_uartps and because
of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking
for irq with request_irq() EINVAL is returned.

Signed-off-by: Michal Simek 
CC: 
Acked-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

tty: serial: fsl_lpuart: clear receive flag on FIFO flush

2015-04-24T21:14:00+00:00

[ Upstream commit 8e4934c6d6c659e22b1b746af4196683e77ce6ca ]

When the receiver was enabled during startup, a character could
have been in the FIFO when the UART get initially used. The
driver configures the (receive) watermark level, and flushes the
FIFO. However, the receive flag (RDRF) could still be set at that
stage (as mentioned in the register description of UARTx_RWFIFO).
This leads to an interrupt which won't be handled properly in
interrupt mode: The receive interrupt function lpuart_rxint checks
the FIFO count, which is 0 at that point (due to the flush
during initialization). The problem does not manifest when using
DMA to receive characters.

Fix this situation by explicitly read the status register, which
leads to clearing of the RDRF flag. Due to the flush just after
the status flag read, a explicit data read is not to required.

Signed-off-by: Stefan Agner 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

tty: serial: fsl_lpuart: specify transmit FIFO size

2015-04-24T21:13:59+00:00

[ Upstream commit 4e8f245937091b2c9eebf3d4909c9ceda4f0a78e ]

Specify transmit FIFO size which might be different depending on
LPUART instance. This makes sure uart_wait_until_sent in serial
core getting called, which in turn waits and checks if the FIFO
is really empty on shutdown by using the tx_empty callback.
Without the call of this callback, the last several characters
might not yet be transmitted when closing the serial port. This
can be reproduced by simply using echo and redirect the output to
a ttyLP device.

Signed-off-by: Stefan Agner 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

n_tty: Fix read buffer overwrite when no newline

2015-04-23T03:26:53+00:00

[ Upstream commit fb5ef9e7da39968fec6d6f37f20a23d23740c75e ]

BugLink: http://bugs.launchpad.net/bugs/1381005

In canon mode, the read buffer head will advance over the buffer tail
if the input > 4095 bytes without receiving a line termination char.

Discard additional input until a line termination is received.
Before evaluating for overflow, the 'room' value is normalized for
I_PARMRK and 1 byte is reserved for line termination (even in !icanon
mode, in case the mode is switched). The following table shows the
transform:

 actual buffer |  'room' value before overflow calc
  space avail  |    !I_PARMRK    |    I_PARMRK
 --------------------------------------------------
      0        |       -1        |       -1
      1        |        0        |        0
      2        |        1        |        0
      3        |        2        |        0
      4+       |        3        |        1

When !icanon or when icanon and the read buffer contains newlines,
normalized 'room' values of -1 and 0 are clamped to 0, and
'overflow' is 0, so read_head is not adjusted and the input i/o loop
exits (setting no_room if called from flush_to_ldisc()). No input
is discarded since the reader does have input available to read
which ensures forward progress.

When icanon and the read buffer does not contain newlines and the
normalized 'room' value is 0, then overflow and room are reset to 1,
so that the i/o loop will process the next input char normally
(except for parity errors which are ignored). Thus, erasures, signalling
chars, 7-bit mode, etc. will continue to be handled properly.

If the input char processed was not a line termination char, then
the canon_head index will not have advanced, so the normalized 'room'
value will now be -1 and 'overflow' will be set, which indicates the
read_head can safely be reset, effectively erasing the last char
processed.

If the input char processed was a line termination, then the
canon_head index will have advanced, so 'overflow' is cleared to 0,
the read_head is not reset, and 'room' is cleared to 0, which exits
the i/o loop (because the reader now have input available to read
which ensures forward progress).

Note that it is possible for a line termination to be received, and
for the reader to copy the line to the user buffer before the
input i/o loop is ready to process the next input char. This is
why the i/o loop recomputes the room/overflow state with every
input char while handling overflow.

Finally, if the input data was processed without receiving
a line termination (so that overflow is still set), the pty
driver must receive a write wakeup. A pty writer may be waiting
to write more data in n_tty_write() but without unthrottling
here that wakeup will not arrive, and forward progress will halt.
(Normally, the pty writer is woken when the reader reads data out
of the buffer and more space become available).

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman 
(backported from commit fb5ef9e7da39968fec6d6f37f20a23d23740c75e)
Signed-off-by: Joseph Salisbury

Change email address for 8250_pci

2015-03-28T13:37:02+00:00

[ Upstream commit f2e0ea861117bda073d1d7ffbd3120c07c0d5d34 ]

I'm still receiving reports to my email address, so let's point this
at the linux-serial mailing list instead.

Cc: 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin