Regression 'tty: fix "IRQ45: nobody cared"'
Regression commit 7b292b4b

  Function reset_buffer_flags() also invoked during the ioctl(...,TCFLSH,..).
At the time of request we can have full buffers and throttled driver too.
If we don't unthrottle driver, we can get forever throttled driver, because,
after request, we will have empty buffers and throttled driver and
there is no place to unthrottle driver.
It simple reproduce with "pty" pair then one side sleep on tty->write_wait,
and other side do ioctl(...,TCFLSH,..). Then there is no place to do writers wake up.
Signed-off-by: NIlya Zykov <ilya@ilyx.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A duplicate definition of the port variable was introduced in the
interrupt handler, which causes the build to break. The fix is to
rename the variable to tport, which is already properly used in
subsequent code.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert the last memory allocation (vt8500_port) to use devm_kzalloc
and remove the fail path cleanup code from vt8500_serial_probe.

Reorder iomem mapping above clk_enable to simplify fail code. The
clock is only enabled if all other resources are available.
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

UART modules on Wondermedia SoCs are connected via a gated clock
source, rather than directly to the 24Mhz reference clock. While
uboot enables UART0 for debugging, other UART ports are unavailable
until the clock is enabled.

This patch checks that a valid clock is actually passed from devicetree,
enables the clock in probe. This change removes the fallback when a
clock was not specified as it doesn't apply any longer (and would only
work if the UART clock was already enabled).

DTSI files are updated for VT8500, WM8505 and WM8650.
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Many of the tty functions were converted to use a struct tty_port
instead of a struct tty_struct. Update the Tegra driver accordingly to
avoid build breakage.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 2e124b4a (TTY: switch tty_flip_buffer_push) introduced the following
build warning:

drivers/tty/serial/imx.c:519:21: warning: unused variable 'tty' [-Wunused-variable]

Remove the unused 'tty' variable.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The write() function could be used by printk(), which is atomic and
tweaking clock there can cause "BUG: sleeping function called from
invalid context".
Signed-off-by: NBao Haojun <hjbao@marvell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fix possible kernel crash if no platform data supplied.
We should not use platform data in this case, instead we will use
default values from private driver structure.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This driver supports the RocketPort EXPRESS and RocketPort INFINITY
families of PCI/PCIe multiport serial adapters.  These adapters use a
"RocketPort 2" ASIC that is not compatible with the original RocketPort
driver (CONFIG_ROCKETPORT).

Tested with the RocketPort EXPRESS Octa DB9 and Quad DB9.  Also added an
old RocketPort 8J PCI card to the same system to verify that rocket.c and
rp2.c coexist peacefully.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Matching PCI_ANY_ID causes conflicts with RocketPort 2 adapters, which
are supported by a different driver.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Memory mapped via ioremap call is never released. Rather than add an
iounmap call, change allocation function to devm_request_and_ioremap.

Also, change the error on failure for this call to -EADDRNOTAVAIL rather than
-ENOMEM.
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix two instances where the index to vt8500_uart_ports is tested
against > VT8500_MAX_PORTS. Correct usage should be >= VT8500_MAX_PORTS.
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The pointer tty is dereferened in line 3135, so it is not necessary to check
null again in line 3140.
Signed-off-by: NCong Ding <dinggnu@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The pointer info is dereferened in line 1009, so it is not necessary to check
null again in line 1012.
Signed-off-by: NCong Ding <dinggnu@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Original table in OMAP TRM named "UART Mode Baud Rates, Divisor
Values, and Error Rates" determines modes not for all common baud
rates. E.g. for 1000000 baud rate mode should be 16x, but according to
that table it's determined as 13x. According to current implementation
of mode divisor selection, after requesting 1000000 baudrate from
driver, later one will configure chip to use MODE13 divisor. Assuming
48Mhz as common UART clock speed, MODE13 divisor will effectively give
1230769 baudrate, what is quite far from desired 1000000 baudrate.
While with MODE16 divisor, chip will produce exact 1000000 baudrate.
In old driver that served UART devices (8250.c and serial_core.c) this
divisor could have been configured by user-space program, but in
omap_serial.c driver implementation this ability was not implemented
(afaik, by design) thus disallowing proper usage of MODE16-compatible
baudrates.
Signed-off-by: NAlexey Pelykh <alexey.pelykh@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit "serial/arc-uart: split probe from probe_earlyprintk" introduced
a build time warning:

"WARNING: vmlinux.o(.data+0x5baa0): Section mismatch in reference from
the variable early_arc_platform_driver to the function
.init.text:arc_serial_probe_earlyprintk()"

While at it - fixed another incorrectly placed initdata annotation.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: fengguang.wu@intel.com
Cc: linux-serial@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The fast lookup table to set baudrate is only right when ioclk
is 150MHz. for most platforms, ioclk is 150MHz, but some boards
might set ioclk to other frequency.

so re-calc the clk_div_reg when ioclk is not 150MHz. this patch
also gets clk in probe and puts it in remove.
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It isn't using the port logic, and breaks the build at the moment, so
mark it BROKEN.

Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

By the recent `switch flipping' patches we introduced a build failure
in the driver:
mn10300-serial.c:527:19: error: 'port' redeclared as different kind of symbol

I did not notice because I did not even find a compiler for that new
architecture. Hopefully everything is all right now as I cannot test
it.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This one was omitted by the "TTY: switch tty_flip_buffer_push" patch
because I did not compile-test mips driver. Now I do.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The default burst is often 1 byte which is not very optimal.
The ideal burst size when using 16550A type port would be
1/2 of fifosize, but this does not work with all Designware
implementations. Setting it to 1/4 fifosize.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are no stubs for ACPI functions so the driver needs to
have this ifdef or it will not compile without ACPI.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove one useless wakeup, and do not use DMA with zero byte
transfers.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The tty buffer functions are converted to using tty_port
structure instead of struct tty, so we must do the same.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since commit 89c8d91e ("tty: localise the lock") I see a dead lock
in one of my dummy_hcd + g_nokia test cases. The first run was usually
okay, the second often resulted in a splat by lockdep and the third was
usually a dead lock.
Lockdep complained about tty->hangup_work and tty->legacy_mutex taken
both ways:
| ======================================================
| [ INFO: possible circular locking dependency detected ]
| 3.7.0-rc6+ #204 Not tainted
| -------------------------------------------------------
| kworker/2:1/35 is trying to acquire lock:
|  (&tty->legacy_mutex){+.+.+.}, at: [<c14051e6>] tty_lock_nested+0x36/0x80
|
| but task is already holding lock:
|  ((&tty->hangup_work)){+.+...}, at: [<c104f6e4>] process_one_work+0x124/0x5e0
|
| which lock already depends on the new lock.
|
| the existing dependency chain (in reverse order) is:
|
| -> #2 ((&tty->hangup_work)){+.+...}:
|        [<c107fe74>] lock_acquire+0x84/0x190
|        [<c104d82d>] flush_work+0x3d/0x240
|        [<c12e6986>] tty_ldisc_flush_works+0x16/0x30
|        [<c12e7861>] tty_ldisc_release+0x21/0x70
|        [<c12e0dfc>] tty_release+0x35c/0x470
|        [<c1105e28>] __fput+0xd8/0x270
|        [<c1105fcd>] ____fput+0xd/0x10
|        [<c1051dd9>] task_work_run+0xb9/0xf0
|        [<c1002a51>] do_notify_resume+0x51/0x80
|        [<c140550a>] work_notifysig+0x35/0x3b
|
| -> #1 (&tty->legacy_mutex/1){+.+...}:
|        [<c107fe74>] lock_acquire+0x84/0x190
|        [<c140276c>] mutex_lock_nested+0x6c/0x2f0
|        [<c14051e6>] tty_lock_nested+0x36/0x80
|        [<c1405279>] tty_lock_pair+0x29/0x70
|        [<c12e0bb8>] tty_release+0x118/0x470
|        [<c1105e28>] __fput+0xd8/0x270
|        [<c1105fcd>] ____fput+0xd/0x10
|        [<c1051dd9>] task_work_run+0xb9/0xf0
|        [<c1002a51>] do_notify_resume+0x51/0x80
|        [<c140550a>] work_notifysig+0x35/0x3b
|
| -> #0 (&tty->legacy_mutex){+.+.+.}:
|        [<c107f3c9>] __lock_acquire+0x1189/0x16a0
|        [<c107fe74>] lock_acquire+0x84/0x190
|        [<c140276c>] mutex_lock_nested+0x6c/0x2f0
|        [<c14051e6>] tty_lock_nested+0x36/0x80
|        [<c140523f>] tty_lock+0xf/0x20
|        [<c12df8e4>] __tty_hangup+0x54/0x410
|        [<c12dfcb2>] do_tty_hangup+0x12/0x20
|        [<c104f763>] process_one_work+0x1a3/0x5e0
|        [<c104fec9>] worker_thread+0x119/0x3a0
|        [<c1055084>] kthread+0x94/0xa0
|        [<c140ca37>] ret_from_kernel_thread+0x1b/0x28
|
|other info that might help us debug this:
|
|Chain exists of:
|  &tty->legacy_mutex --> &tty->legacy_mutex/1 --> (&tty->hangup_work)
|
| Possible unsafe locking scenario:
|
|       CPU0                    CPU1
|       ----                    ----
|  lock((&tty->hangup_work));
|                               lock(&tty->legacy_mutex/1);
|                               lock((&tty->hangup_work));
|  lock(&tty->legacy_mutex);
|
| *** DEADLOCK ***

Before the path mentioned tty_ldisc_release() look like this:

|	tty_ldisc_halt(tty);
|	tty_ldisc_flush_works(tty);
|	tty_lock();

As it can be seen, it first flushes the workqueue and then grabs the
tty_lock. Now we grab the lock first:

|	tty_lock_pair(tty, o_tty);
|	tty_ldisc_halt(tty);
|	tty_ldisc_flush_works(tty);

so lockdep's complaint seems valid.

The earlier version of this patch took the ldisc_mutex since the other
user of tty_ldisc_flush_works() (tty_set_ldisc()) did this.
Peter Hurley then said that it is should not be requried. Since it
wasn't done earlier, I dropped this part.
The code under tty_ldisc_kill() was executed earlier with the tty lock
taken so it is taken again.

I was able to reproduce the deadlock on v3.8-rc1, this patch fixes the
problem in my testcase. I didn't notice any problems so far.

Cc: Alan Cox <alan@linux.intel.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With ACPI 5.0 we can use the FixedDMA Resource Descriptor to
extract the needed information for DMA support.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for dmaengine API. The drivers can implement the
struct uart_8250_dma member in struct uart_8250_port and
8250.c can take care of the rest.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This adds support for ACPI 5.0 enumerated Designware UARTs.
ACPI does not deliver information about uart clk, so
delivering it with the driver_data.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Designware UART provides optional Component Parameter
Register that lists most of the capabilities of the UART,
including FIFO size. This uses that register to set FIFO
size for the port before registering it.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Trivial cleanup. This makes it easier to add different
methods to enumerate the device, for example ACPI 5.0
enumeration.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This needs to be done in order to later access the
Designware specific registers.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Allow 8250.c to determine the port type for us. This allows
the driver take advantage of FIFO on Designware UARTs that
have it.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Modern UARTs are able to provide information about their
capabilities such as FIFO size. This allows the drivers to
deliver this information to 8250.c when they are registering
ports.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Before waking up the tty line discipline idle queue first check if the queue is
active (non empty). This prevents unnecessary entering the critical section in
the wake_up() function and therefore avoid needless scheduling overhead on a
PREEMPT_RT system caused by two processes being in the same critical section.
Signed-off-by: NIvo Sieben <meltedpianoman@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

  for extern function uart_remove_one_port:
    need check pointer whether be NULL, before the main work.
    just like what the other extern function uart_add_one_port has done.
    uart_add_one_port and uart_remove_one_port are pair

  information:
    for the callers (such as drivers/tty/serial/jsm: jsm_tty.c, jsm_driver.c)
    they realy assume that:
      they still can call uart_remove_one_port, after uart_add_one_port failed
    we (as an extern function), have to understand it (just like kfree).
Signed-off-by: NChen Gang <gang.chen@asianux.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use for_each_compatible_node() macro instead of open coding it.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds support for polling work mode, i.e. system is perform
periodical check chip status when IRQ-line is not connected to CPU.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NQuoc-Viet Nguyen <afelion@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that login from util-linux is forced to drop all references to a
TTY which it wants to hangup (to reach reference count 1) we are
seeing issues with telnet. When login closes its last reference to the
slave PTY, it also resets packet mode on the *master* side. And we
have a race here.

What telnet does is fork+exec of `login'. Then there are two
scenarios:
* `login' closes the slave TTY and resets thus master's packet mode,
  but even now telnet properly sets the mode, or
* `telnetd' sets packet mode on the master, `login' closes the slave
  TTY and resets master's packet mode.

The former case is OK. However the latter happens in much more cases,
by the order of magnitude to be precise. So when one tries to login to
such a messed telnet setup, they see the following:
inux login:
            ogin incorrect

Note the missing first letters -- telnet thinks it is still in the
packet mode, so when it receives "linux login" from `login', it
considers "l" as the type of the packet and strips it.

SuS does not mention how the implementation should behave. Both BSDs I
checked (Free and Net) do not reset the flag upon the last close.

By this I am resurrecting an old bug, see References. We are hitting
it regularly now, i.e. with updated util-linux, ergo login.

Here, I am changing a behavior introduced back in 2.1 times. It would
better have a long time testing before goes upstream.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Bryan Mason <bmason@redhat.com>
References: https://lkml.org/lkml/2009/11/11/223
References: https://bugzilla.redhat.com/show_bug.cgi?id=504703
References: https://bugzilla.novell.com/show_bug.cgi?id=797042Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>