Currently, serial drivers don't report buffer overruns. When a buffer overrun
occurs, tty_insert_flip_char returns 0, and no attempt is made to insert that
same character again (i.e. it is lost). This patch reports buffer overruns via
the buf_overrun field in the port's icount structure.
Signed-off-by: NCorbin Atkinson <corbin.atkinson@xxxxxx>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 64218087.

Buffer overruns are for hardware reported overruns, not software ones,
which will only happen if we run out of memory and you will get lots of
-ENOMEM errors at the same time.

Thanks to Alan Cox for catching this.
Reported-by: NAlan Cox <alan@linux.intel.com>
Cc: Corbin Atkinson <corbinat@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is legitimate but because we don't clear the drv->state pointer in the
unregister code causes a bogus BUG().

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, serial drivers don't report buffer overruns. When a buffer overrun
occurs, tty_insert_flip_char returns 0, and no attempt is made to insert that
same character again (i.e. it is lost). This patch reports buffer overruns via
the buf_overrun field in the port's icount structure.
Signed-off-by: NCorbin Atkinson <corbin.atkinson@ni.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

All num, magic and owner are set by alloc_tty_driver. No need to
re-set them on each allocation site.

pti driver sets something different to what it passes to
alloc_tty_driver. It is not a bug, since we don't use the lines
parameter in any way. Anyway this is fixed, and now we do the right
thing.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NTilman Schmidt <tilman@imap.cc>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The synchronize_rcu() call resulting from making every serial driver
wake-up capable (commit b3b708fa) slows boot down on my Tegra2x system
(with CONFIG_PREEMPT disabled).

But this is avoidable since it is the device_set_wakeup_enable() and then
subsequence disable which causes the delay. We might as well just make
the device wakeup capable but not actually enable it for wakeup until
needed.

Effectively the current code does this:

	device_set_wakeup_capable(dev, 1);
	device_set_wakeup_enable(dev, 1);
	device_set_wakeup_enable(dev, 0);

We can just drop the last two lines.

Before this change my boot log says:
[    0.227062] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.702928] serial8250.0: ttyS0 at MMIO 0x70006040 (irq = 69) is a Tegra

after:
[    0.227264] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.227983] serial8250.0: ttyS0 at MMIO 0x70006040 (irq = 69) is a Tegra

for saving of 450ms.
Suggested-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Extract ASYNC_INITIALIZED/TTY_IO_ERROR handling from uart_startup.
This will be useful for tty port helpers. These flags are handled
by the helpers instead.

So we create a new function uart_port_startup without touching these
flags there. And we keep uart_startup with the exact behavior as
before. We need that one because we start/stop the device from other
paths than open/close/hangup.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Let's fill the port_ops->shutdown. We will need this for hangup and
close port helpers.

We don't need to touch DTR/RTS registers in uart_port_shutdown. They
are set to off from port_close_start properly already.

Also we don't need to pin the TTY_IO_ERROR bit. This will be done in
close/hangup paths.

We leave uart_shutdown as is, because it is used (and will be) from
several paths now. Like from suspend.

The point is to not touch ASYNC_INITIALIZED bit. It will be set (and
checked) properly by the tty port helpers.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is a preparation for the next patches which will move the stuff
from uart_open and uart_close/hangup here. Then we will use
tty_port_* helpers.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We need to expand uart_get into uart_open. We need it to move on with
conversion to use tty_port_open helper. After we do this, the code
will be much more similar to what tty_port_open does.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

It is not used at all, so no need to play any games with that.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Just put a kernel-doc comment to uart_change_pm and uart_insert_char.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

After the previous patches, the code is almost identical. There are
few differences in the helper code:
1) flush_buffer when flow_stopped
   * when a user doesn't care about the data, delete it anyways
2) ASYNCB_INITIALIZED test before wait_until_sent_from
   * obviously, there is nothing to wait for if the port is dead
3) drain_delay wait
   * we don't set drain_delay

So we can use the helper now. It indeed removes a bunch of duplicated
code.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

As the tty_port helpers think closing_wait and close_delay are in
jiffies and we want to use the helpers (next patches), we have to
switch the closing_wait and close_delay from ms to jiffies now.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There are some functions (uart_handle_dcd_change, _handle_cts_change,
_insert_char) which are big enough to not be inlined. So move them
from .h to .c. We need to export them so that modules can actually use
them.

They will be even bigger when we introduce tty refcounting to them.

While at it, cleanup the "Proud member of Uglyhacks'R'US". It means,
define uart_handle_sysrq_char only when SUPPORT_SYSRQ is set.
Otherwise define it as a macro. This is needed for some arm driver
where the second parameter is undefined if expanded.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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>

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>

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>

Let's use the newly added helper to avoid stalls in drivers which are
not yet ported to tty_port helpers.

Those which are broken (call tty_wait_until_sent with irqs disabled)
are left untouched. They are in a deeper trouble than we are trying to
solve here. This includes amiserial, 68328serial, 68360serial and
crisv10.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

So now, when we handle CLOSING flag, there is no point to hold
port->mutex over the start of uart_close.

Yes, there are still several things to reason about:
* port->count etc is and always was protected by a spinlock
* ->stop_rx is protected by a spinlock. Otherwise it would
  race with interrupts.
* uart_wait_until_sent -- that one is already called without
  port->mutex from set_termios and tty_set_ldisc. Should anything
  be protected there, it would be tx_empty. And by a spinlock.
  8250 does this internally...

This step is needed to fix system stalls. To not create an AB-BA lock
dependency (see next patches).
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We need to move port->mutex locking after wait_until_sent in
uart_close (for rationale see next patches). But if we did it now, we
would introduce a race between close and open. This is exactly why
port->mutex is locked at the top of uart_close.

To avoid the race, we add ASYNCB_CLOSING to uart_close. Like every
other sane TTY driver. Thanks to tty_port_block_til_ready used in
uart_open we will have this for free. Then we can move the port->mutex
lock.

Also note that this will make the conversion to tty_port helpers
easier. They are currently handling ASYNC_CLOSING flag correctly.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that platforms can override the port IRQ handler and the only user
of these UPIO modes has been converted over, kill off UPIO_DWAPB and
UPIO_DWAPB32.
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We used it really only serial and ami_serial. The rest of the
callsites were BUG/WARN_ONs to check if BTM is held. Now that we
pruned tty_locked from both of the real users, we can get rid of
tty_lock along with __big_tty_mutex_owner.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

tty_wakeup can be called from any context. So there is no need to have
an extra tasklet for calling that. Hence save some space and remove
the tasklet completely.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

During the BKL removal process, the BKL was switched to tty_lock
(BTM). Now we should start pruning the BTM further. Let's start with
wait_until_sent of the serial layer. This will allow us to switch to
the tty port helpers and thus clean it up much.

In wait_until_sent there are some uport members accessed, but neither
of them is protected by BTM at the location they are set ('=>' means
function call):
* uport->fifosize (set in tty_ioctl => uart_ioctl => uart_set_info)
* uport->type (set in add_one_port prior to tty_register_device)
* uport->timeout (set usually in tty_ioctl => tty_mode_ioctl =>
  tty_set_termios => uart_set_termios => uart_change_speed =>
  uport->ops->set_termios => uart_update_timeout)
* call to uport->ops->tx_empty()

If the tx_empty hook needs some lock to protect accesses to registers,
it should take &uport->lock spinlock like 8250 does. Otherwise there
still might be races e.g. with ISRs.

This should also fix the issue Andreas is seeing (BTM in comparison to
BKL doesn't have any hidden functionality like unlocking during
sleeping).
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
References: https://lkml.org/lkml/2011/5/25/562
Cc: Alan Cox <alan@linux.intel.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Cc: Andreas Bombe <aeb@debian.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When a user has SYS_ADMIN capabilities and uart->ops->startup returns
an error in uart_startup, we silently drop the error. We then return 0
and behave as if it didn't fail. (Not quite, since we set TTY_IO_ERROR
bit and leave ASYNC_INITIALIZED bit cleared.)

This all is to allow setserial to work with improperly configured or
unconfigured ports. User can thus set port properties and reconfigure
properly.

This patch only documents this behavior.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Russel King <linux@arm.linux.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

msleep* is guaranteed to return with TASK_RUNNING task state. And
since there is no other set_task_state in the paths of
uart_wait_until_sent, we need not to set_task_state to TASK_RUNNING.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

tty->index (named here as line) is set up in initialize_tty_struct.
The value is checked in get_tty_driver for the found driver as:
	if (device < base || device >= base + p->num)
		continue;
	*index = device - base;

So index/line can never be more than driver->num. Hence remove this
test from uart_open.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Remove stale code in serial_core layer.

Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

remove invalid location line in each file header after location
moved from driver/char to driver/tty
Signed-off-by: NJovi Zhang <bookjovi@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now, uart_update_termios is empty, so it's time to remove it. We no
longer need a live tty in .dtr_rts. So this should prune all the bugs
where tty is zeroed in port->tty during tty_port_block_til_ready.

There is one thing to note. We don't set ASYNC_NORMAL_ACTIVE now. It's
because this is done already in tty_port_block_til_ready.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In .dtr_rts we do:
  uart_set_mctrl(uport, TIOCM_DTR | TIOCM_RTS)
and call uart_update_termios. It does:
  uart_set_mctrl(port, TIOCM_DTR | TIOCM_RTS)
once again. As the only callsite of uart_update_termios is .dtr_rts,
remove the uart_set_mctrl from uart_update_termios to not set it twice.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We should not fiddle with speed and cflags in .dtr_rts hook. Actually
we might not have tty at that moment already.

So move the console cflag copy and speed setup into uart_startup.
Actually the speed setup is already there, but we need to call it
unconditionally (uart_startup is called from uart_open with hw_init =
0).

This means we move uart_change_speed before dtr/rts setup in .dtr_rts.
But this should not matter as the setup should be called after
uart_change_speed anyway.
Before:                             After:
dtr/rts setup (dtr_rts)             uart_change_speed (startup)
uart_change_speed (update_termios)  dtr/rts setup (dtr_rts)
dtr/rts setup (update_termios)      dtr/rts setup (update_termios)

The second setup will dismiss with the next patch.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

drivers/tty/serial/serial_core.c:1980:2: warning: Value stored to 'tty' is never read
        tty = port->tty;
        ^     ~~~~~~~~~
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Only oddities here are a couple of drivers that bogusly called the ldisc
helpers instead of returning -ENOIOCTLCMD. Fix the bug and the rest goes
away.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Doing tiocmget was such fun we should do tiocmset as well for the same
reasons
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We don't actually need this and it causes problems for internal use of
this functionality. Currently there is a single use of the FILE * pointer.
That is the serial core which uses it to check tty_hung_up_p. However if
that is true then IO_ERROR is also already set so the check may be removed.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On some platforms, we need to restore the console speed on resume even
it was not suspended (no_console_suspend), and on others we don't have
to do that.

So don't care about the "console_suspend_enabled" and unconditionally
reset the console speed if it is a console.

This is actually a redo of ba15ab0e (Set proper console speed on resume
if console suspend is disabled) from Deepak Saxena.  I also tried to
investigate more to find out if this change will break others, here is
what I've found out:

commit 891b9dd1
Author: Jason Wang <jason77.wang@gmail.com>
    serial-core: restore termios settings when resume console ports

commit ca2e71aa
Author: Jason Wang <jason77.wang@gmail.com>
    serial-core: skip call set_termios/console_start when no_console_suspend

commit 4547be78
Author: Stanislav Brabec <sbrabec@suse.cz>
    serial-core: resume serial hardware with no_console_suspend

commit ba15ab0e
Author: Deepak Saxena <dsaxena@laptop.org>
    Set proper console speed on resume if console suspend is disabled

from ba15ab0e, we learned that, even if the console suspend is disabled
(when no_console_suspend is set), we may still need to "reset the port
to the state it was in before we suspended."

Then with 4547be78, this piece of code is removed.

And then Jason Wang added that back in ca2e71aa and 891b9dd1, to fix
some breakage on OMAP3EVM platform. From ca2e71aa we learned that the
"set_termios" things is actually needed by both console is suspended
and not suspended.

That's why I removed the console_suspended_enabled condition, and only
call console_start() when we actually suspeneded it.

I also noticed in this thread:
http://marc.info/?t=129079257100004&r=1&w=2, which talked about on
some platforms, UART HW will be cut power whether or not we set
no_console_suspend, and then on resume it does not work quite well. I
have a similar HW, and this patch fixed this issue, don't know if this
patch also works on their platforms.

[Update: Stanislav tested this patch on Zaurus and reported it improves the
situation. Thanks.]

CC: Greg KH <greg@kroah.com>
CC: Deepak Saxena <dsaxena@laptop.org>
CC: Jason Wang <jason77.wang@gmail.com>
CC: Stanislav Brabec <sbrabec@suse.cz>
CC: Daniel Drake <dsd@laptop.org>
Signed-off-by: NYin Kangkai <kangkai.yin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The serial drivers are really just tty drivers, so move them to
drivers/tty/ to make things a bit neater overall.

This is part of the tty/serial driver movement proceedure as proposed by
Arnd Bergmann and approved by everyone involved a number of months ago.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rogier Wolff <R.E.Wolff@bitwizard.nl>
Cc: Michael H. Warfield <mhw@wittsend.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>