<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/tty, branch v3.18.103</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>vt: change SGR 21 to follow the standards</title>
<updated>2018-04-08T09:49:48+00:00</updated>
<author>
<name>Mike Frysinger</name>
<email>vapier@chromium.org</email>
</author>
<published>2018-01-29T22:08:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3307b7be1ffb3302a865074c4d5b94c2884c2ac8'/>
<id>3307b7be1ffb3302a865074c4d5b94c2884c2ac8</id>
<content type='text'>
commit 65d9982d7e523a1a8e7c9af012da0d166f72fc56 upstream.

ECMA-48 [1] (aka ISO 6429) has defined SGR 21 as "doubly underlined"
since at least March 1984.  The Linux kernel has treated it as SGR 22
"normal intensity" since it was added in Linux-0.96b in June 1992.
Before that, it was simply ignored.  Other terminal emulators have
either ignored it, or treat it as double underline now.  xterm for
example added support in its 304 release (May 2014) [2] where it was
previously ignoring it.

Changing this behavior shouldn't be an issue:
- It isn't a named capability in ncurses's terminfo database, so no
  script is using libtinfo/libcurses to look this up, or using tput
  to query &amp; output the right sequence.
- Any script assuming SGR 21 will reset intensity in all terminals
  already do not work correctly on non-Linux VTs (including running
  under screen/tmux/etc...).
- If someone has written a script that only runs in the Linux VT, and
  they're using SGR 21 (instead of SGR 22), the output should still
  be readable.

imo it's important to change this as the Linux VT's non-conformance
is sometimes used as an argument for other terminal emulators to not
implement SGR 21 at all, or do so incorrectly.

[1]: https://www.ecma-international.org/publications/standards/Ecma-048.htm
[2]: https://github.com/ThomasDickey/xterm-snapshots/commit/2fd29cb98d214cb536bcafbee00bc73b3f1eeb9d

Signed-off-by: Mike Frysinger &lt;vapier@chromium.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 65d9982d7e523a1a8e7c9af012da0d166f72fc56 upstream.

ECMA-48 [1] (aka ISO 6429) has defined SGR 21 as "doubly underlined"
since at least March 1984.  The Linux kernel has treated it as SGR 22
"normal intensity" since it was added in Linux-0.96b in June 1992.
Before that, it was simply ignored.  Other terminal emulators have
either ignored it, or treat it as double underline now.  xterm for
example added support in its 304 release (May 2014) [2] where it was
previously ignoring it.

Changing this behavior shouldn't be an issue:
- It isn't a named capability in ncurses's terminfo database, so no
  script is using libtinfo/libcurses to look this up, or using tput
  to query &amp; output the right sequence.
- Any script assuming SGR 21 will reset intensity in all terminals
  already do not work correctly on non-Linux VTs (including running
  under screen/tmux/etc...).
- If someone has written a script that only runs in the Linux VT, and
  they're using SGR 21 (instead of SGR 22), the output should still
  be readable.

imo it's important to change this as the Linux VT's non-conformance
is sometimes used as an argument for other terminal emulators to not
implement SGR 21 at all, or do so incorrectly.

[1]: https://www.ecma-international.org/publications/standards/Ecma-048.htm
[2]: https://github.com/ThomasDickey/xterm-snapshots/commit/2fd29cb98d214cb536bcafbee00bc73b3f1eeb9d

Signed-off-by: Mike Frysinger &lt;vapier@chromium.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tty: vt: fix up tabstops properly</title>
<updated>2018-04-08T09:49:42+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-03-24T09:43:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b1da147c2749874c348f6afdf67ce404a47cfe7c'/>
<id>b1da147c2749874c348f6afdf67ce404a47cfe7c</id>
<content type='text'>
commit f1869a890cdedb92a3fab969db5d0fd982850273 upstream.

Tabs on a console with long lines do not wrap properly, so correctly
account for the line length when computing the tab placement location.

Reported-by: James Holderness &lt;j4_james@hotmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f1869a890cdedb92a3fab969db5d0fd982850273 upstream.

Tabs on a console with long lines do not wrap properly, so correctly
account for the line length when computing the tab placement location.

Reported-by: James Holderness &lt;j4_james@hotmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_pci: Add Brainboxes UC-260 4 port serial device</title>
<updated>2018-03-18T10:15:45+00:00</updated>
<author>
<name>Nikola Ciprich</name>
<email>nikola.ciprich@linuxbox.cz</email>
</author>
<published>2018-02-13T14:04:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=502319ce91249e578323190ee7332c8b43ca9202'/>
<id>502319ce91249e578323190ee7332c8b43ca9202</id>
<content type='text'>
commit 9f2068f35729948bde84d87a40d135015911345d upstream.

Add PCI ids for two variants of Brainboxes UC-260 quad port
PCI serial cards.

Suggested-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Nikola Ciprich &lt;nikola.ciprich@linuxbox.cz&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9f2068f35729948bde84d87a40d135015911345d upstream.

Add PCI ids for two variants of Brainboxes UC-260 quad port
PCI serial cards.

Suggested-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Nikola Ciprich &lt;nikola.ciprich@linuxbox.cz&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tty/serial: atmel: add new version check for usart</title>
<updated>2018-03-18T10:15:44+00:00</updated>
<author>
<name>Jonas Danielsson</name>
<email>jonas@orbital-systems.com</email>
</author>
<published>2018-01-29T11:39:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6515f2dd23e3e6ab6076afb04e57efdbee74462a'/>
<id>6515f2dd23e3e6ab6076afb04e57efdbee74462a</id>
<content type='text'>
commit fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 upstream.

On our at91sam9260 based board the usart0 and usart1 ports report
their versions (ATMEL_US_VERSION) as 0x10302. This version is not
included in the current checks in the driver.

Signed-off-by: Jonas Danielsson &lt;jonas@orbital-systems.com&gt;
Acked-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Acked-by: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 upstream.

On our at91sam9260 based board the usart0 and usart1 ports report
their versions (ATMEL_US_VERSION) as 0x10302. This version is not
included in the current checks in the driver.

Signed-off-by: Jonas Danielsson &lt;jonas@orbital-systems.com&gt;
Acked-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Acked-by: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: sh-sci: prevent lockup on full TTY buffers</title>
<updated>2018-03-18T10:15:44+00:00</updated>
<author>
<name>Ulrich Hecht</name>
<email>ulrich.hecht+renesas@gmail.com</email>
</author>
<published>2018-02-15T12:02:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7353f81f6cc4909019a729f32f2e822895aba845'/>
<id>7353f81f6cc4909019a729f32f2e822895aba845</id>
<content type='text'>
commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream.

When the TTY buffers fill up to the configured maximum, a system lockup
occurs:

[  598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[  598.825796]  0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[  598.832577]  (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[  598.838755] Task dump for CPU 0:
[  598.841977] swapper/0       R  running task        0     0      0 0x00000022
[  598.849023] Call trace:
[  598.851476]  __switch_to+0x98/0xb0
[  598.854870]            (null)

This can be prevented by doing a dummy read of the RX data register.

This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.

Reported-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Ulrich Hecht &lt;ulrich.hecht+renesas@gmail.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Tested-by: Nguyen Viet Dung &lt;dung.nguyen.aj@renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream.

When the TTY buffers fill up to the configured maximum, a system lockup
occurs:

[  598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[  598.825796]  0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[  598.832577]  (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[  598.838755] Task dump for CPU 0:
[  598.841977] swapper/0       R  running task        0     0      0 0x00000022
[  598.849023] Call trace:
[  598.851476]  __switch_to+0x98/0xb0
[  598.854870]            (null)

This can be prevented by doing a dummy read of the RX data register.

This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.

Reported-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Ulrich Hecht &lt;ulrich.hecht+renesas@gmail.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Tested-by: Nguyen Viet Dung &lt;dung.nguyen.aj@renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)</title>
<updated>2018-01-02T19:04:59+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-12-21T01:57:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=95a9e2bf54b89e00a989c4c6c83efbd3cb972516'/>
<id>95a9e2bf54b89e00a989c4c6c83efbd3cb972516</id>
<content type='text'>
commit 966031f340185eddd05affcf72b740549f056348 upstream.

We added support for EXTPROC back in 2010 in commit 26df6d13406d ("tty:
Add EXTPROC support for LINEMODE") and the intent was to allow it to
override some (all?) ICANON behavior.  Quoting from that original commit
message:

         There is a new bit in the termios local flag word, EXTPROC.
         When this bit is set, several aspects of the terminal driver
         are disabled.  Input line editing, character echo, and mapping
         of signals are all disabled.  This allows the telnetd to turn
         off these functions when in linemode, but still keep track of
         what state the user wants the terminal to be in.

but the problem turns out that "several aspects of the terminal driver
are disabled" is a bit ambiguous, and you can really confuse the n_tty
layer by setting EXTPROC and then causing some of the ICANON invariants
to no longer be maintained.

This fixes at least one such case (TIOCINQ) becoming unhappy because of
the confusion over whether ICANON really means ICANON when EXTPROC is set.

This basically makes TIOCINQ match the case of read: if EXTPROC is set,
we ignore ICANON.  Also, make sure to reset the ICANON state ie EXTPROC
changes, not just if ICANON changes.

Fixes: 26df6d13406d ("tty: Add EXTPROC support for LINEMODE")
Reported-by: Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt;
Reported-by: syzkaller &lt;syzkaller@googlegroups.com&gt;
Cc: Jiri Slaby &lt;jslaby@suse.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 966031f340185eddd05affcf72b740549f056348 upstream.

We added support for EXTPROC back in 2010 in commit 26df6d13406d ("tty:
Add EXTPROC support for LINEMODE") and the intent was to allow it to
override some (all?) ICANON behavior.  Quoting from that original commit
message:

         There is a new bit in the termios local flag word, EXTPROC.
         When this bit is set, several aspects of the terminal driver
         are disabled.  Input line editing, character echo, and mapping
         of signals are all disabled.  This allows the telnetd to turn
         off these functions when in linemode, but still keep track of
         what state the user wants the terminal to be in.

but the problem turns out that "several aspects of the terminal driver
are disabled" is a bit ambiguous, and you can really confuse the n_tty
layer by setting EXTPROC and then causing some of the ICANON invariants
to no longer be maintained.

This fixes at least one such case (TIOCINQ) becoming unhappy because of
the confusion over whether ICANON really means ICANON when EXTPROC is set.

This basically makes TIOCINQ match the case of read: if EXTPROC is set,
we ignore ICANON.  Also, make sure to reset the ICANON state ie EXTPROC
changes, not just if ICANON changes.

Fixes: 26df6d13406d ("tty: Add EXTPROC support for LINEMODE")
Reported-by: Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt;
Reported-by: syzkaller &lt;syzkaller@googlegroups.com&gt;
Cc: Jiri Slaby &lt;jslaby@suse.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_pci: Add Amazon PCI serial device ID</title>
<updated>2017-12-09T17:29:48+00:00</updated>
<author>
<name>Matt Wilson</name>
<email>msw@amazon.com</email>
</author>
<published>2017-11-13T19:31:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=01d9d14f89e4cec6a4002974f6e574ec271cc4ea'/>
<id>01d9d14f89e4cec6a4002974f6e574ec271cc4ea</id>
<content type='text'>
commit 3bfd1300abfe3adb18e84a89d97a0e82a22124bb upstream.

This device will be used in future Amazon EC2 instances as the primary
serial port (i.e., data sent to this port will be available via the
GetConsoleOuput [1] EC2 API).

[1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.html

Signed-off-by: Matt Wilson &lt;msw@amazon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3bfd1300abfe3adb18e84a89d97a0e82a22124bb upstream.

This device will be used in future Amazon EC2 instances as the primary
serial port (i.e., data sent to this port will be available via the
GetConsoleOuput [1] EC2 API).

[1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.html

Signed-off-by: Matt Wilson &lt;msw@amazon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sysrq : fix Show Regs call trace on ARM</title>
<updated>2017-12-09T17:29:47+00:00</updated>
<author>
<name>Jibin Xu</name>
<email>jibin.xu@windriver.com</email>
</author>
<published>2017-09-11T03:11:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=079e07453a78efcf3dbee3a40a89a6c31516c224'/>
<id>079e07453a78efcf3dbee3a40a89a6c31516c224</id>
<content type='text'>
[ Upstream commit b00bebbc301c8e1f74f230dc82282e56b7e7a6db ]

When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 &gt;/proc/sys/kernel/sysrq
echo p &gt;/proc/sysrq-trigger
kernel will print call trace as below:

sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [00000000] code: sh/435
caller is __this_cpu_preempt_check+0x18/0x20
Call trace:
[&lt;ffffff8008088e80&gt;] dump_backtrace+0x0/0x1d0
[&lt;ffffff8008089074&gt;] show_stack+0x24/0x30
[&lt;ffffff8008447970&gt;] dump_stack+0x90/0xb0
[&lt;ffffff8008463950&gt;] check_preemption_disabled+0x100/0x108
[&lt;ffffff8008463998&gt;] __this_cpu_preempt_check+0x18/0x20
[&lt;ffffff80084c9194&gt;] sysrq_handle_showregs+0x1c/0x40
[&lt;ffffff80084c9c7c&gt;] __handle_sysrq+0x12c/0x1a0
[&lt;ffffff80084ca140&gt;] write_sysrq_trigger+0x60/0x70
[&lt;ffffff8008251e00&gt;] proc_reg_write+0x90/0xd0
[&lt;ffffff80081f1788&gt;] __vfs_write+0x48/0x90
[&lt;ffffff80081f241c&gt;] vfs_write+0xa4/0x190
[&lt;ffffff80081f3354&gt;] SyS_write+0x54/0xb0
[&lt;ffffff80080833f0&gt;] el0_svc_naked+0x24/0x28

This can be seen on a common board like an r-pi3.
This happens because when echo p &gt;/proc/sysrq-trigger,
get_irq_regs() is called outside of IRQ context,
if preemption is enabled in this situation,kernel will
print the call trace. Since many prior discussions on
the mailing lists have made it clear that get_irq_regs
either just returns NULL or stale data when used outside
of IRQ context,we simply avoid calling it outside of
IRQ context.

Signed-off-by: Jibin Xu &lt;jibin.xu@windriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b00bebbc301c8e1f74f230dc82282e56b7e7a6db ]

When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 &gt;/proc/sys/kernel/sysrq
echo p &gt;/proc/sysrq-trigger
kernel will print call trace as below:

sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [00000000] code: sh/435
caller is __this_cpu_preempt_check+0x18/0x20
Call trace:
[&lt;ffffff8008088e80&gt;] dump_backtrace+0x0/0x1d0
[&lt;ffffff8008089074&gt;] show_stack+0x24/0x30
[&lt;ffffff8008447970&gt;] dump_stack+0x90/0xb0
[&lt;ffffff8008463950&gt;] check_preemption_disabled+0x100/0x108
[&lt;ffffff8008463998&gt;] __this_cpu_preempt_check+0x18/0x20
[&lt;ffffff80084c9194&gt;] sysrq_handle_showregs+0x1c/0x40
[&lt;ffffff80084c9c7c&gt;] __handle_sysrq+0x12c/0x1a0
[&lt;ffffff80084ca140&gt;] write_sysrq_trigger+0x60/0x70
[&lt;ffffff8008251e00&gt;] proc_reg_write+0x90/0xd0
[&lt;ffffff80081f1788&gt;] __vfs_write+0x48/0x90
[&lt;ffffff80081f241c&gt;] vfs_write+0xa4/0x190
[&lt;ffffff80081f3354&gt;] SyS_write+0x54/0xb0
[&lt;ffffff80080833f0&gt;] el0_svc_naked+0x24/0x28

This can be seen on a common board like an r-pi3.
This happens because when echo p &gt;/proc/sysrq-trigger,
get_irq_regs() is called outside of IRQ context,
if preemption is enabled in this situation,kernel will
print the call trace. Since many prior discussions on
the mailing lists have made it clear that get_irq_regs
either just returns NULL or stale data when used outside
of IRQ context,we simply avoid calling it outside of
IRQ context.

Signed-off-by: Jibin Xu &lt;jibin.xu@windriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()</title>
<updated>2017-12-09T17:29:47+00:00</updated>
<author>
<name>Lukas Wunner</name>
<email>lukas@wunner.de</email>
</author>
<published>2017-10-28T09:35:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=826b2a0b10bf91e84fdc220e26e9c7daeda60161'/>
<id>826b2a0b10bf91e84fdc220e26e9c7daeda60161</id>
<content type='text'>
[ Upstream commit 3236a965486ba0c6043cf2c7b51943d8b382ae29 ]

This driver's -&gt;rs485_config callback checks if SER_RS485_RTS_ON_SEND
and SER_RS485_RTS_AFTER_SEND have the same value.  If they do, it means
the user has passed in invalid data with the TIOCSRS485 ioctl()
since RTS must have a different polarity when sending and when not
sending.  In this case, rs485 mode is not enabled (the RS485_URA bit
is not set in the RS485 Enable Register) and this is supposed to be
signaled back to the user by clearing the SER_RS485_ENABLED bit in
struct serial_rs485 ... except a missing tilde character is preventing
that from happening.

Fixes: 28e3fb6c4dce ("serial: Add support for Fintek F81216A LPC to 4 UART")
Cc: Ricardo Ribalda Delgado &lt;ricardo.ribalda@gmail.com&gt;
Cc: "Ji-Ze Hong (Peter Hong)" &lt;hpeter@gmail.com&gt;
Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3236a965486ba0c6043cf2c7b51943d8b382ae29 ]

This driver's -&gt;rs485_config callback checks if SER_RS485_RTS_ON_SEND
and SER_RS485_RTS_AFTER_SEND have the same value.  If they do, it means
the user has passed in invalid data with the TIOCSRS485 ioctl()
since RTS must have a different polarity when sending and when not
sending.  In this case, rs485 mode is not enabled (the RS485_URA bit
is not set in the RS485 Enable Register) and this is supposed to be
signaled back to the user by clearing the SER_RS485_ENABLED bit in
struct serial_rs485 ... except a missing tilde character is preventing
that from happening.

Fixes: 28e3fb6c4dce ("serial: Add support for Fintek F81216A LPC to 4 UART")
Cc: Ricardo Ribalda Delgado &lt;ricardo.ribalda@gmail.com&gt;
Cc: "Ji-Ze Hong (Peter Hong)" &lt;hpeter@gmail.com&gt;
Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: sh-sci: Fix register offsets for the IRDA serial port</title>
<updated>2017-11-15T09:04:12+00:00</updated>
<author>
<name>Laurent Pinchart</name>
<email>laurent.pinchart+renesas@ideasonboard.com</email>
</author>
<published>2017-01-11T14:43:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7d699b09bc9922ccbab82ae6d16553468ded1f91'/>
<id>7d699b09bc9922ccbab82ae6d16553468ded1f91</id>
<content type='text'>
[ Upstream commit a752ba18af8285e3eeda572f40dddaebff0c3621 ]

Even though most of its registers are 8-bit wide, the IRDA has two
16-bit registers that make it a 16-bit peripheral and not a 8-bit
peripheral with addresses shifted by one. Fix the registers offset in
the driver and the platform data regshift value.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a752ba18af8285e3eeda572f40dddaebff0c3621 ]

Even though most of its registers are 8-bit wide, the IRDA has two
16-bit registers that make it a 16-bit peripheral and not a 8-bit
peripheral with addresses shifted by one. Fix the registers offset in
the driver and the platform data regshift value.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
