<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/tty, branch v4.4.171</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.171</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.171'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-12-21T13:09:52+00:00</updated>
<entry>
<title>drivers/tty: add missing of_node_put()</title>
<updated>2018-12-21T13:09:52+00:00</updated>
<author>
<name>Yangtao Li</name>
<email>tiny.windzz@gmail.com</email>
</author>
<published>2018-11-21T15:22:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bf920ab8d61a79f2944beac69526b6d59623c888'/>
<id>urn:sha1:bf920ab8d61a79f2944beac69526b6d59623c888</id>
<content type='text'>
[ Upstream commit dac097c4546e4c5b16dd303a1e97c1d319c8ab3e ]

of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
This place is not doing this, so fix it.

Signed-off-by: Yangtao Li &lt;tiny.windzz@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var()</title>
<updated>2018-12-13T08:21:37+00:00</updated>
<author>
<name>Macpaul Lin</name>
<email>macpaul@gmail.com</email>
</author>
<published>2018-10-17T15:08:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9ef13fecf975e714774d2a1cd49b520b4be9fea4'/>
<id>urn:sha1:9ef13fecf975e714774d2a1cd49b520b4be9fea4</id>
<content type='text'>
commit dada6a43b0402eba438a17ac86fdc64ac56a4607 upstream.

This patch is trying to fix KE issue due to
"BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198"
reported by Syzkaller scan."

[26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198
[26364:syz-executor0][name:report&amp;]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364
[26364:syz-executor0][name:report&amp;]
[26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0
[26364:syz-executor0]Call trace:
[26364:syz-executor0][&lt;ffffff9008095cf8&gt;] dump_bacIctrace+Ox0/0x470
[26364:syz-executor0][&lt;ffffff9008096de0&gt;] show_stack+0x20/0x30
[26364:syz-executor0][&lt;ffffff90089cc9c8&gt;] dump_stack+Oxd8/0x128
[26364:syz-executor0][&lt;ffffff90084edb38&gt;] print_address_description +0x80/0x4a8
[26364:syz-executor0][&lt;ffffff90084ee270&gt;] kasan_report+Ox178/0x390
[26364:syz-executor0][&lt;ffffff90084ee4a0&gt;] _asan_report_loadi_noabort+Ox18/0x20
[26364:syz-executor0][&lt;ffffff9008b092ac&gt;] param_set_kgdboc_var+Ox194/0x198
[26364:syz-executor0][&lt;ffffff900813af64&gt;] param_attr_store+Ox14c/0x270
[26364:syz-executor0][&lt;ffffff90081394c8&gt;] module_attr_store+0x60/0x90
[26364:syz-executor0][&lt;ffffff90086690c0&gt;] sysfs_kl_write+Ox100/0x158
[26364:syz-executor0][&lt;ffffff9008666d84&gt;] kernfs_fop_write+0x27c/0x3a8
[26364:syz-executor0][&lt;ffffff9008508264&gt;] do_loop_readv_writev+0x114/0x1b0
[26364:syz-executor0][&lt;ffffff9008509ac8&gt;] do_readv_writev+0x4f8/0x5e0
[26364:syz-executor0][&lt;ffffff9008509ce4&gt;] vfs_writev+0x7c/Oxb8
[26364:syz-executor0][&lt;ffffff900850ba64&gt;] SyS_writev+Oxcc/0x208
[26364:syz-executor0][&lt;ffffff90080883f0&gt;] elO_svc_naked +0x24/0x28
[26364:syz-executor0][name:report&amp;]
[26364:syz-executor0][name:report&amp;]The buggy address belongs to the variable:
[26364:syz-executor0][name:report&amp;] kgdb_tty_line+Ox3f/0x40
[26364:syz-executor0][name:report&amp;]
[26364:syz-executor0][name:report&amp;]Memory state around the buggy address:
[26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa
[26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
[26364:syz-executor0]&gt; ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
[26364:syz-executor0][name:report&amp;]                                       ^
[26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
[26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa
[26364:syz-executor0][name:report&amp;]
[26364:syz-executor0][name:panic&amp;]Disabling lock debugging due to kernel taint
[26364:syz-executor0]------------[cut here]------------

After checking the source code, we've found there might be an out-of-bounds
access to "config[len - 1]" array when the variable "len" is zero.

Signed-off-by: Macpaul Lin &lt;macpaul@gmail.com&gt;
Acked-by: Daniel Thompson &lt;daniel.thompson@linaro.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>
</entry>
<entry>
<title>tty: serial: 8250_mtk: always resume the device in probe.</title>
<updated>2018-12-13T08:21:37+00:00</updated>
<author>
<name>Peter Shih</name>
<email>pihsun@chromium.org</email>
</author>
<published>2018-11-27T04:49:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dc0e5734399b9d135ed044af983e3ef779b23f0a'/>
<id>urn:sha1:dc0e5734399b9d135ed044af983e3ef779b23f0a</id>
<content type='text'>
commit 100bc3e2bebf95506da57cbdf5f26b25f6da4c81 upstream.

serial8250_register_8250_port calls uart_config_port, which calls
config_port on the port before it tries to power on the port. So we need
the port to be on before calling serial8250_register_8250_port. Change
the code to always do a runtime resume in probe before registering port,
and always do a runtime suspend in remove.

This basically reverts the change in commit 68e5fc4a255a ("tty: serial:
8250_mtk: use pm_runtime callbacks for enabling"), but still use
pm_runtime callbacks.

Fixes: 68e5fc4a255a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling")
Signed-off-by: Peter Shih &lt;pihsun@chromium.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kgdboc: Fix warning with module build</title>
<updated>2018-12-13T08:21:30+00:00</updated>
<author>
<name>Laura Abbott</name>
<email>labbott@redhat.com</email>
</author>
<published>2018-09-20T01:59:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5403677a46a8155ad369e3ca17c9cc6a037b258e'/>
<id>urn:sha1:5403677a46a8155ad369e3ca17c9cc6a037b258e</id>
<content type='text'>
commit 1cd25cbb2fedbc777f3a8c3cb1ba69b645aeaa64 upstream.

After 2dd453168643 ("kgdboc: Fix restrict error"), kgdboc_option_setup is
now only used when built in, resulting in a warning when compiled as a
module:

drivers/tty/serial/kgdboc.c:134:12: warning: 'kgdboc_option_setup' defined but not used [-Wunused-function]
 static int kgdboc_option_setup(char *opt)
            ^~~~~~~~~~~~~~~~~~~

Move the function under the appropriate ifdef for builtin only.

Fixes: 2dd453168643 ("kgdboc: Fix restrict error")
Reported-by: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Laura Abbott &lt;labbott@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kgdboc: Fix restrict error</title>
<updated>2018-12-13T08:21:30+00:00</updated>
<author>
<name>Laura Abbott</name>
<email>labbott@redhat.com</email>
</author>
<published>2018-09-10T23:20:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fa8d814aba4a53fab1b6d2cbc8575a8132fc10df'/>
<id>urn:sha1:fa8d814aba4a53fab1b6d2cbc8575a8132fc10df</id>
<content type='text'>
commit 2dd453168643d9475028cd867c57e65956a0f7f9 upstream.

There's an error when compiled with restrict:

drivers/tty/serial/kgdboc.c: In function ‘configure_kgdboc’:
drivers/tty/serial/kgdboc.c:137:2: error: ‘strcpy’ source argument is the same
as destination [-Werror=restrict]
  strcpy(config, opt);
  ^~~~~~~~~~~~~~~~~~~

As the error implies, this is from trying to use config as both source and
destination. Drop the call to the function where config is the argument
since nothing else happens in the function.

Signed-off-by: Laura Abbott &lt;labbott@redhat.com&gt;
Reviewed-by: Daniel Thompson &lt;daniel.thompson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: wipe buffer if not echoing data</title>
<updated>2018-12-01T08:46:41+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>greg@kroah.com</email>
</author>
<published>2018-10-04T18:06:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b7e9180b4017a28867f27786266cbd4e4a7cf8b'/>
<id>urn:sha1:2b7e9180b4017a28867f27786266cbd4e4a7cf8b</id>
<content type='text'>
commit b97b3d9fb57860a60592859e332de7759fd54c2e upstream.

If we are not echoing the data to userspace or the console is in icanon
mode, then perhaps it is a "secret" so we should wipe it once we are
done with it.

This mirrors the logic that the audit code has.

Reported-by: aszlig &lt;aszlig@nix.build&gt;
Tested-by: Milan Broz &lt;gmazyland@gmail.com&gt;
Tested-by: Daniel Zatovic &lt;daniel.zatovic@gmail.com&gt;
Tested-by: aszlig &lt;aszlig@nix.build&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: wipe buffer.</title>
<updated>2018-12-01T08:46:40+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-10-04T18:06:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d196147ecf0951e15db959cac24d0ce8695a1897'/>
<id>urn:sha1:d196147ecf0951e15db959cac24d0ce8695a1897</id>
<content type='text'>
commit c9a8e5fce009e3c601a43c49ea9dbcb25d1ffac5 upstream.

After we are done with the tty buffer, zero it out.

Reported-by: aszlig &lt;aszlig@nix.build&gt;
Tested-by: Milan Broz &lt;gmazyland@gmail.com&gt;
Tested-by: Daniel Zatovic &lt;daniel.zatovic@gmail.com&gt;
Tested-by: aszlig &lt;aszlig@nix.build&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>termios, tty/tty_baudrate.c: fix buffer overrun</title>
<updated>2018-11-21T08:27:42+00:00</updated>
<author>
<name>H. Peter Anvin</name>
<email>hpa@zytor.com</email>
</author>
<published>2018-10-22T16:19:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=505bc0f3c125f985f4482cacf009437bc26932f9'/>
<id>urn:sha1:505bc0f3c125f985f4482cacf009437bc26932f9</id>
<content type='text'>
commit 991a25194097006ec1e0d2e0814ff920e59e3465 upstream.

On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in tty_baudrate.c does
not do any limit checking on the tty_baudrate[] array, and in fact a
buffer overrun is possible on both architectures. Add a limit check to
prevent that situation.

This will be followed by a much bigger cleanup/simplification patch.

Signed-off-by: H. Peter Anvin (Intel) &lt;hpa@zytor.com&gt;
Requested-by: Cc: Johan Hovold &lt;johan@kernel.org&gt;
Cc: Jiri Slaby &lt;jslaby@suse.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Ivan Kokshaysky &lt;ink@jurassic.park.msu.ru&gt;
Cc: Matt Turner &lt;mattst88@gmail.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Kate Stewart &lt;kstewart@linuxfoundation.org&gt;
Cc: Philippe Ombredanne &lt;pombredanne@nexb.com&gt;
Cc: Eugene Syromiatnikov &lt;esyr@redhat.com&gt;
Cc: Alan Cox &lt;alan@lxorguk.ukuu.org.uk&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sc16is7xx: Fix for multi-channel stall</title>
<updated>2018-11-21T08:27:39+00:00</updated>
<author>
<name>Phil Elwell</name>
<email>phil@raspberrypi.org</email>
</author>
<published>2018-09-12T14:31:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=06bbe23870049ca0bc1541d005efb0b2bdfd9486'/>
<id>urn:sha1:06bbe23870049ca0bc1541d005efb0b2bdfd9486</id>
<content type='text'>
[ Upstream commit 8344498721059754e09d30fe255a12dab8fb03ef ]

The SC16IS752 is a dual-channel device. The two channels are largely
independent, but the IRQ signals are wired together as an open-drain,
active low signal which will be driven low while either of the
channels requires attention, which can be for significant periods of
time until operations complete and the interrupt can be acknowledged.
In that respect it is should be treated as a true level-sensitive IRQ.

The kernel, however, needs to be able to exit interrupt context in
order to use I2C or SPI to access the device registers (which may
involve sleeping).  Therefore the interrupt needs to be masked out or
paused in some way.

The usual way to manage sleeping from within an interrupt handler
is to use a threaded interrupt handler - a regular interrupt routine
does the minimum amount of work needed to triage the interrupt before
waking the interrupt service thread. If the threaded IRQ is marked as
IRQF_ONESHOT the kernel will automatically mask out the interrupt
until the thread runs to completion. The sc16is7xx driver used to
use a threaded IRQ, but a patch switched to using a kthread_worker
in order to set realtime priorities on the handler thread and for
other optimisations. The end result is non-threaded IRQ that
schedules some work then returns IRQ_HANDLED, making the kernel
think that all IRQ processing has completed.

The work-around to prevent a constant stream of interrupts is to
mark the interrupt as edge-sensitive rather than level-sensitive,
but interpreting an active-low source as a falling-edge source
requires care to prevent a total cessation of interrupts. Whereas
an edge-triggering source will generate a new edge for every interrupt
condition a level-triggering source will keep the signal at the
interrupting level until it no longer requires attention; in other
words, the host won't see another edge until all interrupt conditions
are cleared. It is therefore vital that the interrupt handler does not
exit with an outstanding interrupt condition, otherwise the kernel
will not receive another interrupt unless some other operation causes
the interrupt state on the device to be cleared.

The existing sc16is7xx driver has a very simple interrupt "thread"
(kthread_work job) that processes interrupts on each channel in turn
until there are no more. If both channels are active and the first
channel starts interrupting while the handler for the second channel
is running then it will not be detected and an IRQ stall ensues. This
could be handled easily if there was a shared IRQ status register, or
a convenient way to determine if the IRQ had been deasserted for any
length of time, but both appear to be lacking.

Avoid this problem (or at least make it much less likely to happen)
by reducing the granularity of per-channel interrupt processing
to one condition per iteration, only exiting the overall loop when
both channels are no longer interrupting.

Signed-off-by: Phil Elwell &lt;phil@raspberrypi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: check name length in tty_find_polling_driver()</title>
<updated>2018-11-21T08:27:38+00:00</updated>
<author>
<name>Miles Chen</name>
<email>miles.chen@mediatek.com</email>
</author>
<published>2018-10-08T02:39:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7c7378d4c57af308257faf6a5d8af49970a8e218'/>
<id>urn:sha1:7c7378d4c57af308257faf6a5d8af49970a8e218</id>
<content type='text'>
[ Upstream commit 33a1a7be198657c8ca26ad406c4d2a89b7162bcc ]

The issue is found by a fuzzing test.
If tty_find_polling_driver() recevies an incorrect input such as
',,' or '0b', the len becomes 0 and strncmp() always return 0.
In this case, a null p-&gt;ops-&gt;poll_init() is called and it causes a kernel
panic.

Fix this by checking name length against zero in tty_find_polling_driver().

$echo ,, &gt; /sys/module/kgdboc/parameters/kgdboc
[   20.804451] WARNING: CPU: 1 PID: 104 at drivers/tty/serial/serial_core.c:457
uart_get_baud_rate+0xe8/0x190
[   20.804917] Modules linked in:
[   20.805317] CPU: 1 PID: 104 Comm: sh Not tainted 4.19.0-rc7ajb #8
[   20.805469] Hardware name: linux,dummy-virt (DT)
[   20.805732] pstate: 20000005 (nzCv daif -PAN -UAO)
[   20.805895] pc : uart_get_baud_rate+0xe8/0x190
[   20.806042] lr : uart_get_baud_rate+0xc0/0x190
[   20.806476] sp : ffffffc06acff940
[   20.806676] x29: ffffffc06acff940 x28: 0000000000002580
[   20.806977] x27: 0000000000009600 x26: 0000000000009600
[   20.807231] x25: ffffffc06acffad0 x24: 00000000ffffeff0
[   20.807576] x23: 0000000000000001 x22: 0000000000000000
[   20.807807] x21: 0000000000000001 x20: 0000000000000000
[   20.808049] x19: ffffffc06acffac8 x18: 0000000000000000
[   20.808277] x17: 0000000000000000 x16: 0000000000000000
[   20.808520] x15: ffffffffffffffff x14: ffffffff00000000
[   20.808757] x13: ffffffffffffffff x12: 0000000000000001
[   20.809011] x11: 0101010101010101 x10: ffffff880d59ff5f
[   20.809292] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
[   20.809549] x7 : 0000000000000000 x6 : ffffff880d59ff5f
[   20.809803] x5 : 0000000080008001 x4 : 0000000000000003
[   20.810056] x3 : ffffff900853e6b4 x2 : dfffff9000000000
[   20.810693] x1 : ffffffc06acffad0 x0 : 0000000000000cb0
[   20.811005] Call trace:
[   20.811214]  uart_get_baud_rate+0xe8/0x190
[   20.811479]  serial8250_do_set_termios+0xe0/0x6f4
[   20.811719]  serial8250_set_termios+0x48/0x54
[   20.811928]  uart_set_options+0x138/0x1bc
[   20.812129]  uart_poll_init+0x114/0x16c
[   20.812330]  tty_find_polling_driver+0x158/0x200
[   20.812545]  configure_kgdboc+0xbc/0x1bc
[   20.812745]  param_set_kgdboc_var+0xb8/0x150
[   20.812960]  param_attr_store+0xbc/0x150
[   20.813160]  module_attr_store+0x40/0x58
[   20.813364]  sysfs_kf_write+0x8c/0xa8
[   20.813563]  kernfs_fop_write+0x154/0x290
[   20.813764]  vfs_write+0xf0/0x278
[   20.813951]  __arm64_sys_write+0x84/0xf4
[   20.814400]  el0_svc_common+0xf4/0x1dc
[   20.814616]  el0_svc_handler+0x98/0xbc
[   20.814804]  el0_svc+0x8/0xc
[   20.822005] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[   20.826913] Mem abort info:
[   20.827103]   ESR = 0x84000006
[   20.827352]   Exception class = IABT (current EL), IL = 16 bits
[   20.827655]   SET = 0, FnV = 0
[   20.827855]   EA = 0, S1PTW = 0
[   20.828135] user pgtable: 4k pages, 39-bit VAs, pgdp = (____ptrval____)
[   20.828484] [0000000000000000] pgd=00000000aadee003, pud=00000000aadee003, pmd=0000000000000000
[   20.829195] Internal error: Oops: 84000006 [#1] SMP
[   20.829564] Modules linked in:
[   20.829890] CPU: 1 PID: 104 Comm: sh Tainted: G        W         4.19.0-rc7ajb #8
[   20.830545] Hardware name: linux,dummy-virt (DT)
[   20.830829] pstate: 60000085 (nZCv daIf -PAN -UAO)
[   20.831174] pc :           (null)
[   20.831457] lr : serial8250_do_set_termios+0x358/0x6f4
[   20.831727] sp : ffffffc06acff9b0
[   20.831936] x29: ffffffc06acff9b0 x28: ffffff9008d7c000
[   20.832267] x27: ffffff900969e16f x26: 0000000000000000
[   20.832589] x25: ffffff900969dfb0 x24: 0000000000000000
[   20.832906] x23: ffffffc06acffad0 x22: ffffff900969e160
[   20.833232] x21: 0000000000000000 x20: ffffffc06acffac8
[   20.833559] x19: ffffff900969df90 x18: 0000000000000000
[   20.833878] x17: 0000000000000000 x16: 0000000000000000
[   20.834491] x15: ffffffffffffffff x14: ffffffff00000000
[   20.834821] x13: ffffffffffffffff x12: 0000000000000001
[   20.835143] x11: 0101010101010101 x10: ffffff880d59ff5f
[   20.835467] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
[   20.835790] x7 : 0000000000000000 x6 : ffffff880d59ff5f
[   20.836111] x5 : c06419717c314100 x4 : 0000000000000007
[   20.836419] x3 : 0000000000000000 x2 : 0000000000000000
[   20.836732] x1 : 0000000000000001 x0 : ffffff900969df90
[   20.837100] Process sh (pid: 104, stack limit = 0x(____ptrval____))
[   20.837396] Call trace:
[   20.837566]            (null)
[   20.837816]  serial8250_set_termios+0x48/0x54
[   20.838089]  uart_set_options+0x138/0x1bc
[   20.838570]  uart_poll_init+0x114/0x16c
[   20.838834]  tty_find_polling_driver+0x158/0x200
[   20.839119]  configure_kgdboc+0xbc/0x1bc
[   20.839380]  param_set_kgdboc_var+0xb8/0x150
[   20.839658]  param_attr_store+0xbc/0x150
[   20.839920]  module_attr_store+0x40/0x58
[   20.840183]  sysfs_kf_write+0x8c/0xa8
[   20.840183]  sysfs_kf_write+0x8c/0xa8
[   20.840440]  kernfs_fop_write+0x154/0x290
[   20.840702]  vfs_write+0xf0/0x278
[   20.840942]  __arm64_sys_write+0x84/0xf4
[   20.841209]  el0_svc_common+0xf4/0x1dc
[   20.841471]  el0_svc_handler+0x98/0xbc
[   20.841713]  el0_svc+0x8/0xc
[   20.842057] Code: bad PC value
[   20.842764] ---[ end trace a8835d7de79aaadf ]---
[   20.843134] Kernel panic - not syncing: Fatal exception
[   20.843515] SMP: stopping secondary CPUs
[   20.844289] Kernel Offset: disabled
[   20.844634] CPU features: 0x0,21806002
[   20.844857] Memory Limit: none
[   20.845172] ---[ end Kernel panic - not syncing: Fatal exception ]---

Signed-off-by: Miles Chen &lt;miles.chen@mediatek.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
