linux.git/drivers/tty, branch v3.15-rc2

Revert "serial: 8250, disable "too much work" messages"

2014-04-17T16:33:19+00:00

This reverts commit f4f653e9875e573860e783fecbebde284a8626f5.

Jiri writes:
	No, please drop this one. We need a better solution as it turned
	out that some boxes need 16k loops and it will increase with new
	processors :(.

Cc: Jiri Slaby 
Cc: Martin Pluskal 
Cc: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

serial: amba-pl011: fix regression, causing an Oops on rmmod

2014-04-16T21:31:13+00:00

A recent commit ef2889f7ffee67f0aed49e854c72be63f1466759 "serial: pl011:
Move uart_register_driver call to device probe" introduced a regression,
causing the pl011 driver to Oops if more than 1 port have been probed. Fix
the Oops by only calling uart_unregister_driver() once after the last port
has been removed.

Signed-off-by: Guennadi Liakhovetski 
Signed-off-by: Greg Kroah-Hartman

tty: fix memleak in alloc_pid

2014-04-16T21:31:13+00:00

There is memleak in alloc_pid:
------------------------------
unreferenced object 0xd3453a80 (size 64):
  comm "adbd", pid 1730, jiffies 66363 (age 6586.950s)
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 40 c2 f6 d5 00 d3 25 c1 59 28 00 00  ....@.....%.Y(..
  backtrace:
    [] kmemleak_alloc+0x3c/0xa0
    [] kmem_cache_alloc+0xc6/0x190
    [] alloc_pid+0x1e/0x400
    [] copy_process.part.39+0xad4/0x1120
    [] do_fork+0x99/0x330
    [] sys_fork+0x28/0x30
    [] syscall_call+0x7/0xb
    [] 0xffffffff

the leak is due to unreleased pid->count, which execute in function:
get_pid()(pid->count++) and put_pid()(pid->count--).

The race condition as following:
task[dumpsys]               task[adbd]
in disassociate_ctty()      in tty_signal_session_leader()
-----------------------     -------------------------
tty = get_current_tty();
// tty is not NULL
...
spin_lock_irq(¤t->sighand->siglock);
put_pid(current->signal->tty_old_pgrp);
current->signal->tty_old_pgrp = NULL;
spin_unlock_irq(¤t->sighand->siglock);

                            spin_lock_irq(&p->sighand->siglock);
                            ...
                            p->signal->tty = NULL;
                            ...
                            spin_unlock_irq(&p->sighand->siglock);

tty = get_current_tty();
// tty NULL, goto else branch by accident.
if (tty) {
    ...
    put_pid(tty_session);
    put_pid(tty_pgrp);
    ...
} else {
    print msg
}

in task[dumpsys], in disassociate_ctty(), tty is set NULL by task[adbd],
tty_signal_session_leader(), then it goto else branch and lack of
put_pid(), cause memleak.

move spin_unlock(sighand->siglock) after get_current_tty() can avoid
the race and fix the memleak.

Signed-off-by: Zhang Jun 
Signed-off-by: Chen Tingjie 
Signed-off-by: Greg Kroah-Hartman

serial: 8250, disable "too much work" messages

2014-04-16T21:20:34+00:00

The 8250 driver now reports many of these:
  serial8250: too much work for irq4
These messages turned out to be common these days with a use of
virtualization. I tried to increase the limit of processed characters
in commit e7328ae1848966181a7ac47e8ae6cddbd2cf55f3 (serial: 8250,
increase PASS_LIMIT) in 2011. It was raised from 256 to 512, but it is
still not enough, apparently.

So disable the warning unless somebody turns on DEBUG (or
DYNAMIC_DEBUG _and_ the message).

Signed-off-by: Jiri Slaby 
Reported-by: Martin Pluskal 
Reported-by: Takashi Iwai 
Tested-by: Takashi Iwai 
References: https://bugzilla.novell.com/show_bug.cgi?id=868394
Signed-off-by: Greg Kroah-Hartman

serial: omap: Fix missing pm_runtime_resume handling by simplifying code

2014-04-16T21:19:13+00:00

The lack of pm_runtime_resume handling for the device state leads into
device wake-up interrupts not working after a while for runtime PM.

Also, serial-omap is confused about the use of device_may_wakeup.
The checks for device_may_wakeup should only be done for suspend and
resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up
events for PM runtime should always be enabled.

The lack of pm_runtime_resume handling leads into device wake-up
interrupts not working after a while for runtime PM.

Rather than try to patch over the issue of adding complex tests to
the pm_runtime_resume, let's fix the issues properly:

1. Make serial_omap_enable_wakeup deal with all internal PM state
   handling so we don't need to test for up->wakeups_enabled elsewhere.

   Later on once omap3 boots in device tree only mode we can also
   remove the up->wakeups_enabled flag and rely on the wake-up
   interrupt enable/disable state alone.

2. Do the device_may_wakeup checks in suspend and resume only,
   for runtime PM the wake-up events need to be always enabled.

3. Finally just call serial_omap_enable_wakeup and make sure we
   call it also in pm_runtime_resume.

4. Note that we also have to use disable_irq_nosync as serial_omap_irq
   calls pm_runtime_get_sync.

Fixes: 2a0b965cfb6e (serial: omap: Add support for optional wake-up)
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Tony Lindgren 
Acked-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

serial_core: Fix pm imbalance on unbind

2014-04-16T21:19:13+00:00

When a serial port is closed, uart_close() takes care of shutting down the
hardware, and powering it down.

When a serial port is unbound while in use, uart_close() bypasses all of
this, as this is supposed to be done through uart_hangup() (invoked via
tty_vhangup() in uart_remove_one_port()).

However, uart_hangup() does not set the hardware's power state, leaving it
powered up.  This may also lead to unbounded nesting counts in clock and
power management, depending on their internal implementation.

Make sure to power down the port in uart_hangup(), except when the port is
used as a serial console.

For serial consoles, this operation must be postponed until after the port
becomes completely unused. This case is not fixed yet, as it depends on a
(future) fix for the tty->count vs. port->count imbalance on failed
uart_open().

After this, the module clock used by the sh-sci driver is disabled on
unbind while the serial port is in use.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman

serial: pl011: change Rx burst size to half of trigger level

2014-04-16T21:17:44+00:00

The amba-pl011.c driver sets DMA burst size equal to FIFO trigger level.
If now exactly DMA burst size bytes are received, the DMAC will retrieve
them all and no Rx timeout interrupt will be generated. To fix that set
the burst size to half the FIFO trigger level.

Signed-off-by: Guennadi Liakhovetski 
Signed-off-by: Greg Kroah-Hartman

serial: timberdale: Depend on X86_32

2014-04-16T21:17:44+00:00

As far as I know the Timberdale chip was only used as a companion for
Intel Atom E600 series processors. As such, its drivers are only
useful on X86_32.

Signed-off-by: Jean Delvare 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

serial: st-asc: Fix SysRq char handling

2014-04-16T21:17:44+00:00

This driver, like several others, uses the upper bits of the character
to track both real and dummy state. Unfortunately it neglects to mask
these bits properly when passing the character data around. This means
neither break detection nor sysrq character handling work correctly.

This patch adds the requires masking and has been tested to confirm
that it correctly handles magic sysrq sequences on ST's B2020 board.

Signed-off-by: Daniel Thompson 
Signed-off-by: Greg Kroah-Hartman

Revert "serial: clps711x: Give a chance to perform useful tasks during wait loop"

2014-04-16T21:17:44+00:00

This reverts commit 63e3ad3252695a2b8c01b6f6c225e4537af08b85,
since this not works as expected and produce runtime error:

BUG: sleeping function called from invalid context at drivers/tty/serial/clps711x.c:379
in_atomic(): 0, irqs_disabled(): 128, pid: 287, name: mount

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