We are cleaning up the issue that means module.h is omnipresent.
These tty users are the people who implictly are relying on that.
Fix up the real users to call out the include that they really need.

In the case of jsm_driver.c file, it had moduleparam.h but that
isn't enough and it needs the full module.h
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

For simple modules that contain a single platform_driver without any
additional setup code then ends up being a block of duplicated
boilerplate.  This patch adds a new macro, module_platform_driver(),
which replaces the module_init()/module_exit() registrations with
template functions.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Reviewed-by: NMagnus Damm <magnus.damm@gmail.com>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>

This crash was showing up 100% of the time on Tegra CPUs when an
agetty was running on the serial port and the console was not running
on the serial port.  The reason the Tegra saw it so reliably is that
the Tegra CPU internally ties DTR to DCD/DSR.  That means when we
dropped DTR during suspend we would get always get an immediate DCD
drop.

The specific order of operations that were running:
* uart_suspend_port() would be called to put the uart in suspend mode
* we'd drop DTR (ops->set_mctrl(uport, 0)).
* the DTR drop would be looped back in the CPU to be a DCD drop.
* the DCD drop would look to the serial driver as a hangup
* the hangup would call uart_shutdown()
* ... suspend / resume happens ...
* uart_resume_port() would be called and run the code in the
  (port->flags & ASYNC_SUSPENDED) block, which would startup the port
  (and enable tx again).
* Since the UART would be available for tx, we'd immediately get
  an interrupt, eventually calling transmit_chars()
* The transmit_chars() function would crash.  The first crash would
  be a dereference of a NULL tty member, but since the port has been
  shutdown that was just a symptom.

I have proposed a patch that would fix the Tegra CPUs here (see
https://lkml.org/lkml/2011/10/11/444 - tty/serial: Prevent drop of DCD
on suspend for Tegra UARTs).  However, even with that fix it is still
possible for systems that have an externally visible DCD line to see a
crash if the DCD drops at just the right time during suspend: thus
this patch is still useful.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Auto-enumerate mechanism conflicts with bootconsoles: remove
the usage counter for this type of consoles.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit 631180ac.

It caused problems when /dev/tty is a pty:
	https://lkml.org/lkml/2011/10/12/401

Cc: Jiri Slaby <jslaby@suse.cz>
Cc: stable <stable@vger.kernel.org>
Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
Cc: Alan Cox <alan@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Will use aliases to enumerate ports, if available.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If no platform data provided to enumerate ports, use a bit field
to choose port number and check if port is already initialized.
Use this mechanism for both console and plain serial ports.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Easier to follow if platform_data name is pdata.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Commit 4a2b5fdd (Move tty lookup/reopen to caller) made the call to
tty_driver_lookup_tty conditional in tty_open. It doesn't look like it
was an intention. Or if it was, it was not documented in the changelog
and the code now looks weird. For example there would be no need to
remember the tty driver and tty index. Further the condition depends
on a tty which we drop a reference of already.

If I'm looking correctly, this should not matter thanks to the locking
currently done there. Thus, tty_driver->ttys[idx] cannot change under
our hands. But anyway, it makes sense to change that to the old
behaviour.

Introduced-in: v2.6.28-rc2
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: stable <stable@vger.kernel.org>
Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
Cc: Alan Cox <alan@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Mistakenly, commit 64ba3dc3 (tty: never hold BTM while getting
tty_mutex) switched one fail path in ptmx_open to not free the newly
allocated tty.

Fix that by jumping to the appropriate place. And rename the labels so
that it's clear what is going on there.

Introduced-in: v2.6.36-rc2
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: stable <stable@vger.kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If tty_add_file fails at the point it is now, we have to revert all
the changes we did to the tty. It means either decrease all refcounts
if this was a tty reopen or delete the tty if it was newly allocated.

There was a try to fix this in v3.0-rc2 using tty_release in 0259894c
(TTY: fix fail path in tty_open). But instead it introduced a NULL
dereference. It's because tty_release dereferences
filp->private_data, but that one is set even in our tty_add_file. And
when tty_add_file fails, it's still NULL/garbage. Hence tty_release
cannot be called there.

To circumvent the original leak (and the current NULL deref) we split
tty_add_file into two functions, making the latter non-failing. In
that case we may do the former early in open, where handling failures
is easy. The latter stays as it is now. So there is no change in
functionality.

The original bug (leak) was introduced by f573bd17 (tty: Remove
__GFP_NOFAIL from tty_add_file()). Thanks Dan for reporting this.

Later, we may split tty_release into more functions and call only some
of them in this fail path instead. (If at all possible.)

Introduced-in: v2.6.37-rc2
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: stable <stable@vger.kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When tty_driver_lookup_tty fails in tty_open, we forget to drop a
reference to the tty driver. This was added by commit 4a2b5fdd (Move
tty lookup/reopen to caller).

Fix that by adding tty_driver_kref_put to the fail path.

I will refactor the code later. This is for the ease of backporting to
stable.

Introduced-in: v2.6.28-rc2
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: stable <stable@vger.kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: NSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently, ".setup" function is not set.
As a result, when detecting our IOH's uart device without pch_uart, kernel panic
occurs at the following of pciserial_init_ports().

	for (i = 0; i < nr_ports; i++) {
		if (quirk->setup(priv, board, &serial_port, i))
			break;

So, this patch adds the ".setup" function.
We can use pci_default_setup because our IOH's uart is compatible with 16550.
Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When running a Fedora 15 (x86) on an x86_64 kernel, in the boot process
plymouthd complains about those two missing ioctls:
[    2.581783] ioctl32(plymouthd:186): Unknown cmd fd(10) cmd(00005457){t:'T';sz:0} arg(ffb6a5d0) on /dev/tty1
[    2.581803] ioctl32(plymouthd:186): Unknown cmd fd(10) cmd(00005456){t:'T';sz:0} arg(ffb6a680) on /dev/tty1

both ioctl functions work on the 'struct termios' resp. 'struct termios2',
which has the same size (36 bytes resp. 44 bytes) on x86 and x86_64,
so it's just a matter of converting the pointer from userland.
Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

printk only works for "registered consoles."  Currently, the hvc_console
code calls register_console() from hvc_instantiate(), but that's only
used in the early console case.  In hvc_alloc(), register_console() was
not called.

Add a call to register_console() in hvc_alloc(), set up the index in
the hvc_console, and set up the necessary vtermnos[] and cons_op[]
entries so that printk functions work.
Signed-off-by: NMiche Baker-Harvey <miche@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Introduce the config option CONFIG_VT_CONSOLE_SLEEP in order to cleanup
the #if defined ugliness for the vt suspend support functions. Note that
CONFIG_VT_CONSOLE is already dependant on CONFIG_VT.

The function pm_set_vt_switch is actually dependant on CONFIG_VT and not
CONFIG_PM_SLEEP. This fixes a compile error when CONFIG_PM_SLEEP is
not set:

drivers/tty/vt/vt_ioctl.c:1794: error: redefinition of 'pm_set_vt_switch'
include/linux/suspend.h:17: error: previous definition of 'pm_set_vt_switch' was here

Also, remove the incorrect path from the comment in console.c.

[rjw: Replaced #if defined() with #ifdef in suspend.h.]
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

HW_CONSOLE doesn't need to depend on both VT and !S390 as VT already
depends on !S390.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch fixes the following build error caused by commit
85888069 ("tty: use of_match_ptr() for of_match_table entry").
The problem was a missing #include <linux/of.h> which is where
of_match_ptr() is defined.

drivers/tty/serial/altera_jtaguart.c:483:3: error: implicit declaration of function 'of_match_ptr' [-Werror=implicit-function-declaration]
drivers/tty/serial/altera_jtaguart.c:483:34: error: 'altera_jtaguart_match' undeclared here (not in a function)
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Tobias Klauser <tklauser@distanz.ch> (maintainer:ALTERA UART/JTAG...)
Cc: Alan Cox <alan@linux.intel.com> (maintainer:SERIAL DRIVERS)

Use the new of_match_ptr() macro for the of_match_table
pointer entry to avoid having to #dfine match NULL
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

My main concern here was the line that said:
	copy_count = min_t(unsigned short,count,SCABUFSIZE);
"count" is an unsigned int here so the cast to unsigned short
truncates the upper bits.  So if count is 0x10000 then copy_count is
0 and the loop never exits.

"count" comes from skb->len in hdlcdev_xmit().

The other min_t() changes are just cleanups.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

n_gsm use a simple approach: every writing to fifo correspond exactly one
reading from fifo. There are no problem in this approach until we read
less bytes then we write. As result fifo may owerflow. This leads to packet
loss and very slow responce.

For example, this happens with ping packets (about 96 byte each) and default
gsm->mtu = 64. As result we get 50 sec ping timeout and 20% packet loss.

Fix the problem by reading and sending all data from the fifo
Signed-off-by: NMikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

in adaption=2 case we should put 1 or 2 byte with modem status bits
at the beginning of a buffer pointed by "dp". n_gsm use 1 byte case,
so it allocate a buffer of len + 1 size. As result we should:
  * put 1 byte of modem status bits
  * increase data pointer
  * put "len" bytes of data
but actually we have:
  * increase first byte with the value of modem status bits
  * decrease "len"
  * put orig_len - 1 bytes of data starting from the buffer beggining
This is evidently wrong.
Signed-off-by: NMikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On my BIOSTAR TA890FXE the ttyS0 ends up spewing:

[904682.485933] ttyS0: LSR safety check engaged!
[904692.505895] ttyS0: LSR safety check engaged!
[904702.525972] ttyS0: LSR safety check engaged!
[904712.545967] ttyS0: LSR safety check engaged!
[904722.566125] ttyS0: LSR safety check engaged!
..
lets limit it so it won't be the only thing visible
in the ring buffer.

CC: Alan Cox <alan@linux.intel.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Clear bitmask was not inverted before masking modem_tx.

Calling ioctl(fd, TIOCMBIC, TIOCM_RTS) results in:

[  197.430000] pre_modem_tx:	0x00000006
[  197.430000] clear:			0x00000004
[  197.430000] set:			0x00000000
[  197.440000] post_modem_tx:	0x00000004

which is wrong.
Signed-off-by: NNikola Diklic-Perin <diklic.perin.nikola@gmail.com>
Acked-by: NAlan Cox <alan@linx.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The ePAPR hypervisor byte channel console driver only supports one byte
channel as a console, and the byte channel handle is stored in a global
variable.  It doesn't make any sense to pass that handle as a parameter
to the console functions, since these functions already have access to the
global variable.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn when handler enables interrupts]).

So now this flag is a NOOP and can be removed.
Signed-off-by: NYong Zhang <yong.zhang0@gmail.com>
Acked-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The following patch removed uart_change_pm() in uart_resume_port():

commit 5933a161
Author: Yin Kangkai <kangkai.yin@linux.intel.com>
    serial-core: reset the console speed on resume

It will break the pxa serial driver when the system resumes from suspend mode
as it will try to set baud rate divider register in set_termios but with
clock off. The register value can not be set correctly on some platform if
the clock is disabled. The pxa driver will check the value and report the
following warning:

------------[ cut here ]------------
WARNING: at drivers/tty/serial/pxa.c:545 serial_pxa_set_termios+0x1dc/0x250()
Modules linked in:
[<c0281f30>] (unwind_backtrace+0x0/0xf0) from [<c029341c>] (warn_slowpath_common+0x4c/0x64)
[<c029341c>] (warn_slowpath_common+0x4c/0x64) from [<c029344c>] (warn_slowpath_null+0x18/0x1c)
[<c029344c>] (warn_slowpath_null+0x18/0x1c) from [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250)
[<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250) from [<c044a840>] (uart_resume_port+0x128/0x2dc)
[<c044a840>] (uart_resume_port+0x128/0x2dc) from [<c044bbe0>] (serial_pxa_resume+0x18/0x24)
[<c044bbe0>] (serial_pxa_resume+0x18/0x24) from [<c0454d34>] (platform_pm_resume+0x40/0x4c)
[<c0454d34>] (platform_pm_resume+0x40/0x4c) from [<c0457ebc>] (pm_op+0x68/0xb4)
[<c0457ebc>] (pm_op+0x68/0xb4) from [<c0458368>] (device_resume+0xb0/0xec)
[<c0458368>] (device_resume+0xb0/0xec) from [<c04584c8>] (dpm_resume+0xe0/0x194)
[<c04584c8>] (dpm_resume+0xe0/0x194) from [<c0458588>] (dpm_resume_end+0xc/0x18)
[<c0458588>] (dpm_resume_end+0xc/0x18) from [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac)
[<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac) from [<c02c5278>] (enter_state+0xac/0xdc)
[<c02c5278>] (enter_state+0xac/0xdc) from [<c02c48ec>] (state_store+0xa0/0xbc)
[<c02c48ec>] (state_store+0xa0/0xbc) from [<c0408f7c>] (kobj_attr_store+0x18/0x1c)
[<c0408f7c>] (kobj_attr_store+0x18/0x1c) from [<c034a6a4>] (sysfs_write_file+0x108/0x140)
[<c034a6a4>] (sysfs_write_file+0x108/0x140) from [<c02fb798>] (vfs_write+0xac/0x134)
[<c02fb798>] (vfs_write+0xac/0x134) from [<c02fb8cc>] (sys_write+0x3c/0x68)
[<c02fb8cc>] (sys_write+0x3c/0x68) from [<c027c700>] (ret_fast_syscall+0x0/0x2c)
---[ end trace 88289eceb4675b04 ]---

This patch fix the problem by adding the power on opertion back for uart
console when console_suspend_enabled is true.
Signed-off-by: NNing Jiang <ning.jiang@marvell.com>
Tested-by: NMayank Rana <mrana@codeaurora.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Cc: gregkh@suse.de
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The top of <linux/irq.h> has this comment:

 * Please do not include this file in generic code.  There is currently
 * no requirement for any architecture to implement anything held
 * within this file.
 *
 * Thanks. --rmk

Remove inclusion of <linux/irq.>, to prevent the following compile error
from happening soon:

| include/linux/irq.h:132: error: redefinition of ‘struct irq_data’
| include/linux/irq.h:286: error: redefinition of ‘struct irq_chip’

drivers/tty/vt/keyboard.c needs to include <asm/irq_regs.h> for get_irq_regs():

| drivers/tty/vt/keyboard.c:497: error: implicit declaration of function ‘get_irq_regs’
| drivers/tty/vt/keyboard.c:497: warning: initialization makes pointer from integer without a cast
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This driver has been broken at least since 2008. At that time,
a88487c7 (Fix compile errors in SGI console drivers) broke this
driver completely.

And since nobody noticed for the past 3 years, move it into staging. I
think this will rot there and we will throw it away completely after
some time. Or maybe someone will volunteer to fix it ;).
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

KERN_CRIT is too high, replace those KERN_CRIT with KERN_ERR or KERN_WARNING.

Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: NWANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The EFR (Enhenced-Features-Register) is located at a different offset
than the other devices supporting UART_CAP_EFR. This change add a special
setup quick to set UPF_EXAR_EFR on the port. UPF_EXAR_EFR is then used to
the port type to PORT_XR17D15X since it is for sure a XR17D15X uart.
Signed-off-by: NSøren Holm <sgh@sgh.dk>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fixes the following build error:

drivers/tty/serial/crisv10.c:4453: error: 'if_ser0' undeclared (first use in this function): 2 errors in 2 logs
        v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig
drivers/tty/serial/crisv10.c:4453: error: (Each undeclared identifier is reported only once: 2 errors in 2 logs
        v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig
drivers/tty/serial/crisv10.c:4453: error: for each function it appears in.): 2 errors in 2 logs
        v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig

"if_ser0" is a typo, it should be "if_serial_0".

Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: NWANG Cong <xiyou.wangcong@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

linux/tty_flip.h is included in linux/serial_core.h. But this may (and
will) change in the future. Then we would get build errors such as:
.../tty/serial/max3107.c: In function ‘put_data_to_circ_buf’:
.../tty/serial/max3107.c:149:2: error: implicit declaration of function ‘tty_insert_flip_string’

So fix all the drviers which call tty flip buffer helpers to really
include linux/tty_flip.h. And also make sure that those include
linux/tty.h when operating with struct tty_struct.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The code is dead at least since 2002. So remove it to not distort git
grep output (about port.tty usage).

Remove the whole do_softirq tasklet as it's noop now.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When mutex_lock is not called, mutex_unlock is sometimes called.
This deletes unnecessary goto and makes modifications so that
mutex_unlock is called.

[    8.304000] WARNING: at kernel/muex-debug.c:78
[    8.304000] Modules linked in:
[    8.304000]
[    8.304000] Pid : 114, Comm:                 modprobe
[    8.304000] CPU : 0                  Not tainted  (3.1.0-rc3-next-20110826 #810)
[    8.304000]
[    8.304000] PC is at debug_mutex_unlock+0xf4/0x120
[    8.304000] PR is at debug_mutex_unlock+0xe6/0x120
[    8.304000] PC  : 80051114 SP  : 9f02de58 SR  : 400081f1 TEA : 295cf4f2
[    8.304000] R0  : 00000001 R1  : 00000000 R2  : 0000000f R3  : 00000000
[    8.304000] R4  : 9fc63158 R5  : 00000000 R6  : 00000001 R7  : 9fe1de78
[    8.304000] R8  : 805c6b2c R9  : 80003920 R10 : 00000000 R11 : 805c6b2c
[    8.304000] R12 : 80425ca0 R13 : 00000000 R14 : 9f02de58
[    8.304000] MACH: 00000003 MACL: 00000000 GBR : 296e1678 PR  : 80051106
[    8.304000]
[    8.304000] Call trace:
[    8.304000]  [<804236c6>] __mutex_unlock_slowpath+0x46/0x120
[    8.304000]  [<804237aa>] mutex_unlock+0xa/0x20
[    8.304000]  [<80240ed6>] uart_close+0x76/0x2c0
[    8.304000]  [<80223b98>] tty_release+0xf8/0x5c0
[    8.304000]  [<800a93a6>] lookup_object+0x26/0xa0
[    8.304000]  [<80063f6a>] call_rcu+0x8a/0xc0
[    8.304000]  [<800a944a>] put_object+0x2a/0x60
[    8.304000]  [<80003920>] arch_local_irq_restore+0x0/0x40
[    8.304000]  [<800af320>] fput+0x180/0x2c0
[    8.304000]  [<800af248>] fput+0xa8/0x2c0
[    8.304000]  [<800ab1a8>] filp_close+0x48/0xc0
[    8.304000]  [<800ab29a>] sys_close+0x7a/0x100
[    8.304000]  [<8000825a>] syscall_call+0xc/0x10
[    8.304000]  [<800ab220>] sys_close+0x0/0x100
[    8.304000]
[    8.304000] Code:
[    8.304000]   8005110e:  mov.l     @r1, r1
[    8.304000]   80051110:  tst       r1, r1
[    8.304000]   80051112:  bf        80051116
[    8.304000] ->80051114:  trapa     #62
[    8.304000]   80051116:  mov.l     @r8, r1
[    8.304000]   80051118:  tst       r1, r1
[    8.304000]   8005111a:  bt.s      8005104c
[    8.304000]   8005111c:  mov       #0, r1
[    8.304000]   8005111e:  bra       80051056
[    8.304000]
[    8.304000] ---[ end trace e8f8e04c313f429b ]---
Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Errata E20: UART: Character Timeout interrupt remains set under certain
software conditions.

Implication: The software servicing the UART can be trapped in an infinite loop.
Signed-off-by: NMarcus Folkesson <marcus.folkesson@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>