commit 24d406a6bf upstream.
tty_operations->remove is normally called like:
queue_release_one_tty
->tty_shutdown
->tty_driver_remove_tty
->tty_operations->remove
However tty_shutdown() is called from queue_release_one_tty() only if
tty_operations->shutdown is NULL. But for pty, it is not.
pty_unix98_shutdown() is used there as ->shutdown.
So tty_operations->remove of pty (i.e. pty_unix98_remove()) is never
called. This results in invalid pty_count. I.e. what can be seen in
/proc/sys/kernel/pty/nr.
I see this was already reported at:
https://lkml.org/lkml/2009/11/5/370
But it was not fixed since then.
This patch is kind of a hackish way. The problem lies in ->install. We
allocate there another tty (so-called tty->link). So ->install is
called once, but ->remove twice, for both tty and tty->link. The fix
here is to count both tty and tty->link and divide the count by 2 for
user.
And to have ->remove called, let's make tty_driver_remove_tty() global
and call that from pty_unix98_shutdown() (tty_operations->shutdown).
While at it, let's document that when ->shutdown is defined,
tty_shutdown() is not called.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 8c4074cd22 upstream.
Since commit e0626e38 (spi: prefix modalias with "spi:"),
the spi modalias is prefixed with "spi:".
This patch adds "spi:" prefix and removes "-spi" suffix in the modalias.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit dbb3b1ca56 upstream.
This is to fix an issue where output will suddenly become very slow.
The problem occurs on 8250 UARTS with the hardware bug UART_BUG_THRE.
BACKGROUND
For normal UARTs (without UART_BUG_THRE): When the serial core layer
gets new transmit data and the transmitter is idle, it buffers the
data and calls the 8250s' serial8250_start_tx() routine which will
simply enable the TX interrupt in the IER register and return. This
should immediately fire a THRE interrupt and begin transmitting the
data.
For buggy UARTs (with UART_BUG_THRE): merely enabling the TX interrupt
in IER does not necessarily generate a new THRE interrupt.
Therefore, a background timer periodically checks to see if there is
pending data, and starts transmission if that is the case.
The bug happens on SMP systems when the system has nothing to transmit,
the transmit interrupt is disabled and the following sequence occurs:
- CPU0: The background timer routine serial8250_backup_timeout()
starts and saves the state of the interrupt enable register (IER)
and then disables all interrupts in IER. NOTE: The transmit interrupt
(TI) bit is saved as disabled.
- CPU1: The serial core gets data to transmit, grabs the port lock and
calls serial8250_start_tx() which enables the TI in IER.
- CPU0: serial8250_backup_timeout() waits for the port lock.
- CPU1: finishes (with TI enabled) and releases the port lock.
- CPU0: serial8250_backup_timeout() calls the interrupt routine which
will transmit the next fifo's worth of data and then restores the
IER from the previously saved value (TI disabled).
At this point, as long as the serial core has more transmit data
buffered, it will not call serial8250_start_tx() again and the
background timer routine will slowly transmit the data.
The fix is to have serial8250_start_tx() get the port lock before
it saves the IER state and release it after restoring IER. This will
prevent serial8250_start_tx() from running in parallel.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 44178176ec upstream.
This patch adds support for the Rosewill RC-305 four-port PCI serial
card, and probably any other four-port serial cards based on the
Moschip MCS9865 chip, assuming that the EEPROM on the card was
programmed in accordance with Table 6 of the MCS9865 EEPROM
Application Note version 0.3 dated 16-May-2008, available from the
Moschip web site (registration required).
This patch is based on an earlier patch [1] for the SYBA 6x serial
port card by Ira W. Snyder.
[1]: http://www.gossamer-threads.com/lists/linux/kernel/1162435
Signed-off-by: Eric Smith <eric@brouhaha.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit b280a97d1c upstream.
Fixes logic bug that software flow control cannot be disabled, because
serial_omap_configure_xonxoff() is not called if both IXON and IXOFF bits
are cleared.
Signed-off-by: Nick Pelly <npelly@google.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Tested-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 8c2381af0d upstream.
Currently, the hvc_console_print() function drops console output if the
hvc backend's put_chars() returns 0. This patch changes this behavior
to allow a retry through returning -EAGAIN.
This change also affects the hvc_push() function. Both functions are
changed to handle -EAGAIN and to retry the put_chars() operation.
If a hvc backend returns -EAGAIN, the retry handling differs:
- hvc_console_print() spins to write the complete console output.
- hvc_push() behaves the same way as for returning 0.
Now hvc backends can indirectly control the way how console output is
handled through the hvc console layer.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Acked-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f2eb3cdf14 upstream.
Kconfig allows enabling console support for the SC26xx driver even when
it's configured as a module resulting in a:
ERROR: "uart_console_device" [drivers/tty/serial/sc26xx.ko] undefined!
modpost error since the driver was merged in
eea63e0e8a [SC26XX: New serial driver for
SC2681 uarts] in 2.6.25. Fixed by only allowing console support to be
enabled if the driver is builtin.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 5568181f18 upstream.
Commit 4539c24fe4 "tty/serial: Add
explicit PORT_TEGRA type" introduced separate flags describing the need
for IER bits UUE and RTOIE. Both bits are required for the XSCALE port
type. While that patch updated uart_config[] as required, the auto-probing
code wasn't updated to set the RTOIE flag when an XSCALE port type was
detected. This caused such ports to stop working. This patch rectifies
that.
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f086ced171 upstream.
FCS could be GSM0_SOF, so will break state machine...
[This byte isn't quoted in any way so a SOF here doesn't imply an error
occurred.]
Signed-off-by: Alek Du <alek.du@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
[Trivial but best backported once its in 3.1rc I think]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'at91/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-2.6-arm-soc:
AT91: Change nand buswidth logic to match hardware default configuration
at91: Use "pclk" as con_id on at91cap9 and at91rm9200
at91: fix udc, ehci and mmc clock device name for cap9/9g45/9rl
atmel_serial: fix internal port num
at91: fix at91_set_serial_console: use platform device id
* 'tty-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6:
serial: bcm63xx_uart: fix irq storm after rx fifo overrun.
amba pl011: platform data for reg lockup and glitch v2
amba pl011: workaround for uart registers lockup
tty: n_gsm: improper skb_pull() use was leaking framed data
tty: n_gsm: Fixed logic to decode break signal from modem status
TTY: ntty, add one more sanity check
TTY: ldisc, do not close until there are readers
8250: Fix capabilities when changing the port type
8250_pci: Fix missing const from merges
ARM: SAMSUNG: serial: Fix on handling of one clock source for UART
serial: ioremap warning fix for jsm driver.
8250_pci: add -ENODEV code for Intel EG20T PCH
the atmel_ports is link to the console number and not the device id
this was not detected on at91 as we always register the dbgu on the console
as ttyS0
tested on at91sam9263 by setting the dbgu as ttyS1 and use as console
diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
index 70e5646..9b8a14f 100644
- a/arch/arm/mach-at91/board-sam9263ek.c
+ b/arch/arm/mach-at91/board-sam9263ek.c
@@ -58,14 +58,14 @@ static void __init ek_init_early(void)
/* Initialize processor: 16.367 MHz crystal */
at91_initialize(16367660);
- /* DBGU on ttyS0. (Rx & Tx only) */
- at91_register_uart(0, 0, 0);
+ /* DBGU on ttyS1. (Rx & Tx only) */
+ at91_register_uart(0, 1, 0);
- /* USART0 on ttyS1. (Rx, Tx, RTS, CTS) */
- at91_register_uart(AT91SAM9263_ID_US0, 1, ATMEL_UART_CTS | ATMEL_UART_RTS);
+ /* USART0 on ttyS0. (Rx, Tx, RTS, CTS) */
+ at91_register_uart(AT91SAM9263_ID_US0, 0, ATMEL_UART_CTS | ATMEL_UART_RTS);
- /* set serial console to ttyS0 (ie, DBGU) */
- at91_set_serial_console(0);
+ /* set serial console to ttyS1 (ie, DBGU) */
+ at91_set_serial_console(1);
}
/*
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
The driver went to initialize its waitqueue at the start of the main
processing thread. However, it is possible that this thread is not
scheduled on a CPU before the write function is called which leads to a
following error:
BUG: spinlock bad magic on CPU#1, swapper/1
lock: f5f3ebdc, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
Pid: 1, comm: swapper Not tainted 3.0.0-rc2+ #67
Call Trace:
[<c1289663>] spin_bug+0xa3/0xf0
[<c12897ad>] do_raw_spin_lock+0x7d/0x150
[<c14963de>] _raw_spin_lock_irqsave+0x4e/0x60
[<c102f2bb>] __wake_up+0x1b/0x50
[<c12d3715>] serial_m3110_con_write+0x55/0x60
[<c1041575>] __call_console_drivers+0x75/0x90
[<c10415d9>] _call_console_drivers+0x49/0x80
[<c1041baa>] console_unlock+0xca/0x1f0
[<c10420ef>] vprintk+0x18f/0x4f0
[<c14928a3>] printk+0x18/0x1a
[<c1042730>] register_console+0x2e0/0x350
[<c12d098e>] uart_add_one_port+0x33e/0x3d0
[<c1485ba6>] serial_m3110_probe+0x1c2/0x1df
[<c1303db7>] spi_drv_probe+0x17/0x20
...
Fix this by initializing the waitqueue before the main thread is
created.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change print message to notice instead of error to clean up non critical
messages showing on startup. The MAX3111 not being present is a normal
path for end user systems.
Signed-off-by: William Douglas <william.douglas@intel.com>
[rebased on 3.0, switched to dev_dbg()]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This workaround aims to break the deadlock situation
which raises during continuous transfer of data for long
duration over uart with hardware flow control. It is
observed that CTS interrupt cannot be cleared in uart
interrupt register (ICR). Hence further transfer over
uart gets blocked.
It is seen that during such deadlock condition ICR
don't get cleared even on multiple write. This leads
pass_counter to decrease and finally reach zero. This
can be taken as trigger point to run this UART_BT_WA.
Workaround backups the register configuration, does soft
reset of UART using BIT-0 of PRCC_K_SOFTRST_SET/CLEAR
registers and restores the registers.
This patch also provides support for uart init and exit
function calls if present.
Signed-off-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
gsm_dlci_data_output_framed() was doing:
memcpy(dp, skb_pull(dlci->skb, len), len);
The problem is skb_pull() returns the post-increment data ptr
so the first chunk of dlci->skb->data is leaked.
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The modem status can be one or 2 octets and contains the V.24 signals
and in the 2 octet case also the break signal.
We were improperly decoding the break signal from the modem in the
2 octet case.
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The flush_to_ldisc() work entry has special logic to notice when it has
seen the original tail of the data queue, and it avoids continuing the
flush if it sees that _original_ tail rather than the current tail.
This logic can trigger in case somebody is constantly adding new data to
the tty while the flushing is active - and the intent is to avoid
excessive CPU usage while flushing the tty, especially as we used to do
this from a softirq context which made it non-preemptible.
However, since we no longer re-arm the work-queue from within itself
(because that causes other trouble: see commit a5660b41af "tty: fix
endless work loop when the buffer fills up"), this just leads to
possible hung tty's (most easily seen in SMP and with a test-program
that floods a pty with data - nobody seems to have reported this for any
real-life situation yet).
And since the workqueue isn't done from timers and softirq's any more,
it's doubtful whether the CPU useage issue is really relevant any more.
So just remove the logic entirely, and see if anybody ever notices.
Alternatively, we might want to re-introduce the "re-arm the work" for
just this case, but then we'd have to re-introduce the delayed work
model or some explicit timer, which really doesn't seem worth it for
this.
Reported-and-tested-by: Guillaume Chazarain <guichaz@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With the previous patch, we fixed another bug where read_buf was freed
while we still was in n_tty_read. We currently check whether read_buf
is NULL at the start of the function. Add one more check after we wake
up from waiting for input.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We restored tty_ldisc_wait_idle in 100eeae2c5 (TTY: restore
tty_ldisc_wait_idle). We used it in the ldisc changing path to fix the
case where there are tasks in n_tty_read waiting for data and somebody
tries to change ldisc.
Similar to the case above, there may be also tasks waiting in
n_tty_read while hangup is performed. As 65b770468e (tty-ldisc: turn
ldisc user count into a proper refcount) removed the wait-until-idle
from all paths, hangup path won't wait for them to disappear either
now. So add it back even to the hangup path.
There is a difference, we need uninterruptible sleep as there is
obviously HUP signal pending. So tty_ldisc_wait_idle now sleeps
without possibility to be interrupted. This is what original
tty_ldisc_wait_idle did. After the wait idle reintroduction
(100eeae2c5), we have had interruptible sleeps for the ldisc changing
path. But as there is a 5s timeout anyway, we don't allow it to be
interrupted from now on. It's not worth the added complexity of
deciding what kind of sleep we want.
Before 65b770468e tty_ldisc_release was called also from
tty_ldisc_release. It is called from tty_release, so I don't think we
need to restore that one.
This is nicely reproducible after constifying the timing when
drivers/tty/n_tty.c is patched as follows ("TTY: ntty, add one more
sanity check" patch is needed to actually see it explode):
%% -1548,6 +1549,7 @@ static int n_tty_open(struct tty_struct *tty)
/* These are ugly. Currently a malloc failure here can panic */
if (!tty->read_buf) {
+ msleep(100);
tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL);
if (!tty->read_buf)
return -ENOMEM;
%% -1785,6 +1788,7 @@ do_it_again:
break;
}
timeout = schedule_timeout(timeout);
+ msleep(20);
continue;
}
__set_current_state(TASK_RUNNING);
===== With a process: =====
while (1) {
int fd = open(argv[1], O_RDWR);
read(fd, buf, sizeof(buf));
close(fd);
}
===== and its child: =====
setsid();
while (1) {
int fd = open(tty, O_RDWR|O_NOCTTY);
ioctl(fd, TIOCSCTTY, 1);
vhangup();
close(fd);
usleep(100 * (10 + random() % 1000));
}
===== EOF =====
References: https://bugzilla.novell.com/show_bug.cgi?id=693374
References: https://bugzilla.novell.com/show_bug.cgi?id=694509
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable <stable@kernel.org> [32, 33, 34, 39]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When changing the port type, the capabilities flags should be changed
also, otherwise the capabilities will not correspond to the port type,
which make set_sleep() crash on rmmod.
This patch just assign the correct capabilites when the port changes.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
CC: Michael Reed <mreed@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
