linux-stable.git/drivers/tty, branch v3.4.106 Linux kernel stable tree tty/vt: don't set font mappings on vc not supporting this 2015-02-02T09:05:15+00:00 Imre Deak imre.deak@intel.com 2014-10-02T13:34:31+00:00 0bb9566eaaabf31b2368340fbedc34010c09e8f0 commit 9e326f78713a4421fe11afc2ddeac07698fac131 upstream. We can call this function for a dummy console that doesn't support setting the font mapping, which will result in a null ptr BUG. So check for this case and return error for consoles w/o font mapping support. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=59321 Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: just return -EINVAL as we don't need to unlock] Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 9e326f78713a4421fe11afc2ddeac07698fac131 upstream.

We can call this function for a dummy console that doesn't support
setting the font mapping, which will result in a null ptr BUG. So check
for this case and return error for consoles w/o font mapping support.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=59321
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: just return -EINVAL as we don't need to unlock]
Signed-off-by: Zefan Li <lizefan@huawei.com>
tty: Prevent "read/write wait queue active!" log flooding 2015-02-02T09:05:15+00:00 Peter Hurley peter@hurleysoftware.com 2014-10-16T17:54:36+00:00 871518e986137e72b3ad20e5b3fd7093cda69bbf commit 494c1eac7e73f719af9d474a96ec8494c33efd6a upstream. Only print one warning when a task is on the read_wait or write_wait wait queue at final tty release. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 494c1eac7e73f719af9d474a96ec8494c33efd6a upstream.

Only print one warning when a task is on the read_wait or write_wait
wait queue at final tty release.

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
tty: Fix high cpu load if tty is unreleaseable 2015-02-02T09:05:15+00:00 Peter Hurley peter@hurleysoftware.com 2014-10-16T17:51:30+00:00 26bc3aa52a38602cc5a4430571d90e158430573b commit 37b164578826406a173ca7c20d9ba7430134d23e upstream. Kernel oops can cause the tty to be unreleaseable (for example, if n_tty_read() crashes while on the read_wait queue). This will cause tty_release() to endlessly loop without sleeping. Use a killable sleep timeout which grows by 2n+1 jiffies over the interval [0, 120 secs.) and then jumps to forever (but still killable). NB: killable just allows for the task to be rewoken manually, not to be terminated. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 37b164578826406a173ca7c20d9ba7430134d23e upstream.

Kernel oops can cause the tty to be unreleaseable (for example, if
n_tty_read() crashes while on the read_wait queue). This will cause
tty_release() to endlessly loop without sleeping.

Use a killable sleep timeout which grows by 2n+1 jiffies over the interval
[0, 120 secs.) and then jumps to forever (but still killable).

NB: killable just allows for the task to be rewoken manually, not
to be terminated.

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
serial: Fix divide-by-zero fault in uart_get_divisor() 2015-02-02T09:05:15+00:00 Peter Hurley peter@hurleysoftware.com 2014-10-16T17:46:38+00:00 741946cf911c1ea1cefcf790baaeb618b0712d0f commit 547039ec502076e60034eeb79611df3433a99b7d upstream. uart_get_baud_rate() will return baud == 0 if the max rate is set to the "magic" 38400 rate and the SPD_* flags are also specified. On the first iteration, if the current baud rate is higher than the max, the baud rate is clamped at the max (which in the degenerate case is 38400). On the second iteration, the now-"magic" 38400 baud rate selects the possibly higher alternate baud rate indicated by the SPD_* flag. Since only two loop iterations are performed, the loop is exited, a kernel WARNING is generated and a baud rate of 0 is returned. Reproducible with: setserial /dev/ttyS0 spd_hi base_baud 38400 Only perform the "magic" 38400 -> SPD_* baud transform on the first loop iteration, which prevents the degenerate case from recognizing the clamped baud rate as the "magic" 38400 value. Reported-by: Robert Święcki <robert@swiecki.net> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 547039ec502076e60034eeb79611df3433a99b7d upstream.

uart_get_baud_rate() will return baud == 0 if the max rate is set
to the "magic" 38400 rate and the SPD_* flags are also specified.
On the first iteration, if the current baud rate is higher than the
max, the baud rate is clamped at the max (which in the degenerate
case is 38400). On the second iteration, the now-"magic" 38400 baud
rate selects the possibly higher alternate baud rate indicated by
the SPD_* flag. Since only two loop iterations are performed, the
loop is exited, a kernel WARNING is generated and a baud rate of
0 is returned.

Reproducible with:
 setserial /dev/ttyS0 spd_hi base_baud 38400

Only perform the "magic" 38400 -> SPD_* baud transform on the first
loop iteration, which prevents the degenerate case from recognizing
the clamped baud rate as the "magic" 38400 value.

Reported-by: Robert Święcki <robert@swiecki.net>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
serial: 8250: Add Quark X1000 to 8250_pci.c 2015-02-02T09:04:45+00:00 Bryan O'Donoghue pure.logic@nexus-software.ie 2014-09-23T00:21:11+00:00 a06f6a5d229bbf9fcb0f39a9dbee56dda06f363a commit 1ede7dcca3c4fa15a518ab0473126f9c3e621e4c upstream. Quark X1000 contains two designware derived 8250 serial ports. Each port has a unique PCI configuration space consisting of BAR0:UART BAR1:DMA respectively. Unlike the standard 8250 the register width is 32 bits for RHR,IER etc The Quark UART has a fundamental clock @ 44.2368 MHz allowing for a bitrate of up to about 2.76 megabits per second. This patch enables standard 8250 mode Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 1ede7dcca3c4fa15a518ab0473126f9c3e621e4c upstream.

Quark X1000 contains two designware derived 8250 serial ports.
Each port has a unique PCI configuration space consisting of
BAR0:UART BAR1:DMA respectively.

Unlike the standard 8250 the register width is 32 bits for RHR,IER etc
The Quark UART has a fundamental clock @ 44.2368 MHz allowing for a
bitrate of up to about 2.76 megabits per second.

This patch enables standard 8250 mode

Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
8250_pci: fix warnings in backport of Broadcom TruManage support 2014-09-25T03:49:18+00:00 Paul Gortmaker paul.gortmaker@windriver.com 2014-08-25T17:33:20+00:00 82a938ab75f966ee228ee85665cd074c5d078b42 commit 7400ce7ee9595432b2a1402b6ffcac9faf38d9ae (v3.4.92-76-g7400ce7ee959) was a backport of commit ebebd49a8eab5e9aa1b1f8f1614ccc3c2120f886 upstream ("8250/16?50: Add support for Broadcom TruManage redirected serial port") However, in the context of 3.4.x kernels, the pci setup code was expecting a struct uart_port and not a struct uart_8250_port, leading to the following concerning warnings: drivers/tty/serial/8250/8250_pci.c: In function ‘pci_brcm_trumanage_setup’: drivers/tty/serial/8250/8250_pci.c:1086:2: warning: passing argument 3 of ‘pci_default_setup’ from incompatible pointer type [enabled by default] int ret = pci_default_setup(priv, board, port, idx); ^ drivers/tty/serial/8250/8250_pci.c:1036:1: note: expected ‘struct uart_port *’ but argument is of type ‘struct uart_8250_port *’ pci_default_setup(struct serial_private *priv, ^ drivers/tty/serial/8250/8250_pci.c: At top level: drivers/tty/serial/8250/8250_pci.c:1746:3: warning: initialization from incompatible pointer type [enabled by default] .setup = pci_brcm_trumanage_setup, ^ drivers/tty/serial/8250/8250_pci.c:1746:3: warning: (near initialization for ‘pci_serial_quirks[56].setup’) [enabled by default] I'd also expect the initialization to not function correctly, and perhaps dereference random garbage due to this. Since the uart_port is a field within the uart_8250_port, the adaptation to fix these warnings is a straightforward removal of a layer of indirection. Cc: Stephen Hurd <shurd@broadcom.com> Cc: Michael Chan <mchan@broadcom.com> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Rui Xiang <rui.xiang@huawei.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Zefan Li <lizefan@huawei.com> 
commit 7400ce7ee9595432b2a1402b6ffcac9faf38d9ae (v3.4.92-76-g7400ce7ee959)
was a backport of commit ebebd49a8eab5e9aa1b1f8f1614ccc3c2120f886 upstream
("8250/16?50: Add support for Broadcom TruManage redirected serial port")

However, in the context of 3.4.x kernels, the pci setup code was
expecting a struct uart_port and not a struct uart_8250_port, leading to
the following concerning warnings:

drivers/tty/serial/8250/8250_pci.c: In function ‘pci_brcm_trumanage_setup’:
drivers/tty/serial/8250/8250_pci.c:1086:2: warning: passing argument 3 of ‘pci_default_setup’ from incompatible pointer type [enabled by default]
  int ret = pci_default_setup(priv, board, port, idx);
  ^
drivers/tty/serial/8250/8250_pci.c:1036:1: note: expected ‘struct uart_port *’ but argument is of type ‘struct uart_8250_port *’
 pci_default_setup(struct serial_private *priv,
 ^
drivers/tty/serial/8250/8250_pci.c: At top level:
drivers/tty/serial/8250/8250_pci.c:1746:3: warning: initialization from incompatible pointer type [enabled by default]
   .setup  = pci_brcm_trumanage_setup,
   ^
drivers/tty/serial/8250/8250_pci.c:1746:3: warning: (near initialization for ‘pci_serial_quirks[56].setup’) [enabled by default]

I'd also expect the initialization to not function correctly, and
perhaps dereference random garbage due to this.  Since the uart_port
is a field within the uart_8250_port, the adaptation to fix these
warnings is a straightforward removal of a layer of indirection.

Cc: Stephen Hurd <shurd@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Rui Xiang <rui.xiang@huawei.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
sunsab: Fix detection of BREAK on sunsab serial console 2014-08-14T00:42:37+00:00 Christopher Alexander Tobias Schulze cat.schulze@alice-dsl.net 2014-08-03T14:01:53+00:00 a46e9456f1516e8238d43dcff766595452c0ed48 [ Upstream commit fe418231b195c205701c0cc550a03f6c9758fd9e ] Fix detection of BREAK on sunsab serial console: BREAK detection was only performed when there were also serial characters received simultaneously. To handle all BREAKs correctly, the check for BREAK and the corresponding call to uart_handle_break() must also be done if count == 0, therefore duplicate this code fragment and pull it out of the loop over the received characters. Patch applies to 3.16-rc6. Signed-off-by: Christopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit fe418231b195c205701c0cc550a03f6c9758fd9e ]

Fix detection of BREAK on sunsab serial console: BREAK detection was only
performed when there were also serial characters received simultaneously.
To handle all BREAKs correctly, the check for BREAK and the corresponding
call to uart_handle_break() must also be done if count == 0, therefore
duplicate this code fragment and pull it out of the loop over the received
characters.

Patch applies to 3.16-rc6.

Signed-off-by: Christopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty/serial: Add support for Altera serial port 2014-06-11T19:04:22+00:00 Ley Foon Tan lftan@altera.com 2013-03-07T02:28:37+00:00 85faa17c6abc754dac48a82f3d9bc70dd1c7453b commit e06c93cacb82dd147266fd1bdb2d0a0bd45ff2c1 upstream. Add support for Altera 8250/16550 compatible serial port. Signed-off-by: Ley Foon Tan <lftan@altera.com> [xr: Backported to 3.4: adjust filenames, context] Signed-off-by: Rui Xiang <rui.xiang@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e06c93cacb82dd147266fd1bdb2d0a0bd45ff2c1 upstream.

Add support for Altera 8250/16550 compatible serial port.

Signed-off-by: Ley Foon Tan <lftan@altera.com>
[xr: Backported to 3.4: adjust filenames, context]
Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8250/16?50: Add support for Broadcom TruManage redirected serial port 2014-06-11T19:04:22+00:00 Stephen Hurd shurd@broadcom.com 2013-01-17T22:14:53+00:00 7400ce7ee9595432b2a1402b6ffcac9faf38d9ae commit ebebd49a8eab5e9aa1b1f8f1614ccc3c2120f886 upstream. Add support for the UART device present in Broadcom TruManage capable NetXtreme chips (ie: 5761m 5762, and 5725). This implementation has a hidden transmit FIFO, so running in single-byte interrupt mode results in too many interrupts. The UART_CAP_HFIFO capability was added to track this. It continues to reload the THR as long as the THRE and TSRE bits are set in the LSR up to a specified limit (1024 is used here). Signed-off-by: Stephen Hurd <shurd@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> [xr: Backported to 3.4: - Adjust filenames - Adjust context - PORT_BRCM_TRUMANAGE is 22 not 24] Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Rui Xiang <rui.xiang@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ebebd49a8eab5e9aa1b1f8f1614ccc3c2120f886 upstream.

Add support for the UART device present in Broadcom TruManage capable
NetXtreme chips (ie: 5761m 5762, and 5725).

This implementation has a hidden transmit FIFO, so running in single-byte
interrupt mode results in too many interrupts.  The UART_CAP_HFIFO
capability was added to track this.  It continues to reload the THR as long
as the THRE and TSRE bits are set in the LSR up to a specified limit (1024
is used here).

Signed-off-by: Stephen Hurd <shurd@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
[xr: Backported to 3.4:
 - Adjust filenames
 - Adjust context
 - PORT_BRCM_TRUMANAGE is 22 not 24]
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix 4 port and add support for 8 port 'Unknown' PCI serial port cards 2014-06-11T19:04:21+00:00 Scott Ashcroft scott.ashcroft@talk21.com 2013-03-03T21:35:06+00:00 eb2249dc3d9d9c6ce6f8bd292770ff72400faab6 commit d13402a4a944e72612a9ec5c9190e35717c02a9d upstream. I've managed to find an 8 port version of the card 4 port card which was discussed here: http://marc.info/?l=linux-serial&m=120760744205314&w=2 Looking back at that thread there were two issues in the original patch. 1) The I/O ports for the UARTs are within BAR2 not BAR0. This can been seen in the original post. 2) A serial quirk isn't needed as these cards have no memory in BAR0 which makes pci_plx9050_init just return. This patch fixes the 4 port support to use BAR2, removes the bogus quirk and adds support for the 8 port card. $ lspci -vvv -n -s 00:08.0 00:08.0 0780: 10b5:9050 (rev 01) Subsystem: 10b5:1588 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 17 Region 1: I/O ports at ff00 [size=128] Region 2: I/O ports at fe00 [size=64] Region 3: I/O ports at fd00 [size=8] Capabilities: <access denied> Kernel driver in use: serial $ dmesg | grep 0000:00:08.0: [ 0.083320] pci 0000:00:08.0: [10b5:9050] type 0 class 0x000780 [ 0.083355] pci 0000:00:08.0: reg 14: [io 0xff00-0xff7f] [ 0.083369] pci 0000:00:08.0: reg 18: [io 0xfe00-0xfe3f] [ 0.083382] pci 0000:00:08.0: reg 1c: [io 0xfd00-0xfd07] [ 0.083460] pci 0000:00:08.0: PME# supported from D0 D3hot [ 1.212867] 0000:00:08.0: ttyS4 at I/O 0xfe00 (irq = 17) is a 16550A [ 1.233073] 0000:00:08.0: ttyS5 at I/O 0xfe08 (irq = 17) is a 16550A [ 1.253270] 0000:00:08.0: ttyS6 at I/O 0xfe10 (irq = 17) is a 16550A [ 1.273468] 0000:00:08.0: ttyS7 at I/O 0xfe18 (irq = 17) is a 16550A [ 1.293666] 0000:00:08.0: ttyS8 at I/O 0xfe20 (irq = 17) is a 16550A [ 1.313863] 0000:00:08.0: ttyS9 at I/O 0xfe28 (irq = 17) is a 16550A [ 1.334061] 0000:00:08.0: ttyS10 at I/O 0xfe30 (irq = 17) is a 16550A [ 1.354258] 0000:00:08.0: ttyS11 at I/O 0xfe38 (irq = 17) is a 16550A Signed-off-by: Scott Ashcroft <scott.ashcroft@talk21.com> [xr: Backported to 3.4: adjust context] Signed-off-by: Rui Xiang <rui.xiang@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d13402a4a944e72612a9ec5c9190e35717c02a9d upstream.

I've managed to find an 8 port version of the card 4 port card which was discussed here:

http://marc.info/?l=linux-serial&m=120760744205314&w=2

Looking back at that thread there were two issues in the original patch.

1) The I/O ports for the UARTs are within BAR2 not BAR0. This can been seen in the original post.
2) A serial quirk isn't needed as these cards have no memory in BAR0 which makes pci_plx9050_init just return.

This patch fixes the 4 port support to use BAR2, removes the bogus quirk and adds support for the 8 port card.

$ lspci -vvv -n -s 00:08.0
00:08.0 0780: 10b5:9050 (rev 01)
	Subsystem: 10b5:1588
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 17
	Region 1: I/O ports at ff00 [size=128]
	Region 2: I/O ports at fe00 [size=64]
	Region 3: I/O ports at fd00 [size=8]
	Capabilities: <access denied>
	Kernel driver in use: serial

$ dmesg | grep 0000:00:08.0:
[    0.083320] pci 0000:00:08.0: [10b5:9050] type 0 class 0x000780
[    0.083355] pci 0000:00:08.0: reg 14: [io  0xff00-0xff7f]
[    0.083369] pci 0000:00:08.0: reg 18: [io  0xfe00-0xfe3f]
[    0.083382] pci 0000:00:08.0: reg 1c: [io  0xfd00-0xfd07]
[    0.083460] pci 0000:00:08.0: PME# supported from D0 D3hot
[    1.212867] 0000:00:08.0: ttyS4 at I/O 0xfe00 (irq = 17) is a 16550A
[    1.233073] 0000:00:08.0: ttyS5 at I/O 0xfe08 (irq = 17) is a 16550A
[    1.253270] 0000:00:08.0: ttyS6 at I/O 0xfe10 (irq = 17) is a 16550A
[    1.273468] 0000:00:08.0: ttyS7 at I/O 0xfe18 (irq = 17) is a 16550A
[    1.293666] 0000:00:08.0: ttyS8 at I/O 0xfe20 (irq = 17) is a 16550A
[    1.313863] 0000:00:08.0: ttyS9 at I/O 0xfe28 (irq = 17) is a 16550A
[    1.334061] 0000:00:08.0: ttyS10 at I/O 0xfe30 (irq = 17) is a 16550A
[    1.354258] 0000:00:08.0: ttyS11 at I/O 0xfe38 (irq = 17) is a 16550A

Signed-off-by: Scott Ashcroft <scott.ashcroft@talk21.com>
[xr: Backported to 3.4: adjust context]
Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>