- Aug 03, 2022
-
-
Douglas Anderson authored
When we multiply an unsigned int by a u32 we still end up with an unsigned int. That means we should specify "%u" not "%lu" in the format code. NOTE: this fix was chosen instead of somehow promoting the value to "unsigned long" since the max baud rate from the earlier call to uart_get_baud_rate() is 4000000 and the max sampling rate is 32. 4000000 * 32 = 0x07a12000, not even close to overflowing 32-bits. Fixes: c474c775 ("tty: serial: qcom-geni-serial: Fix get_clk_div_rate() which otherwise could return a sub-optimal clock rate.") Reported-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220802132250.1.Iea061e14157a17e114dbe2eca764568a02d6b889@changeid Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Jul 28, 2022
-
-
Jason Wang authored
The double `should' is duplicated in line 15, remove one. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Link: https://lore.kernel.org/r/20220715054401.9870-1-wangborong@cdjrlc.com Signed-off-by:
-
Jiri Slaby authored
This was the only function mentioned in the text, but was neither linked nor documented. So document and link it, so that hyperlinking works in the text. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220728061056.20799-6-jslaby@suse.cz Signed-off-by:
-
Jiri Slaby authored
There are many annotated functions in serial_core.c, but they do not completely conform to the kernel-doc style. So reformat them and link them from the Documentation. Signed-off-by:
-
Jiri Slaby authored
The syntax to reference a struct in text is "struct XY". So reference uart_ops properly, so that hyperlinks work. Signed-off-by:
-
Jiri Slaby authored
The GPIO uart functions are documented in Documentation. Move and transform this documentation into kernel-doc directly in the code and reference it in Documentation using kernel-doc:. This makes it easier to update, maintain and check by the build. Signed-off-by:
-
Jiri Slaby authored
Some of the serial (uart_*) functions are documented twice. Once as kernel-doc along their sources and once in Documentation. So deduplicate these texts, merge them into kernel-doc in the sources, and link them using kernel-doc: from the Documentation. To be properly linked and rendered, tabulators had to be removed from the comments. Signed-off-by:
-
Jiri Slaby authored
While it's a lot of text, it always helps to keep it up to date when it's by the source. (And not in a separate file.) The documentation tooling also makes sure that all members of the structure are documented. (If not, it complains loudly.) Finally, there needs to be no comments inlined in the structure, so they are dropped as they are superfluous now. The compilation time of this header (tested with serial_core.c) didn't change in my testing at all. Signed-off-by:
-
Jagan Teki authored
Document compatible string for Rockchip RV1126 SoC. Signed-off-by:
Jagan Teki <jagan@edgeble.ai> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220723204335.750095-13-jagan@edgeble.ai Signed-off-by:
-
Narendra Hadke authored
For mvebu uart2, error bits are not cleared on buffer read. This causes interrupt loop and system hang. Cc: stable@vger.kernel.org Reviewed-by:
Yi Guo <yi.guo@cavium.com> Reviewed-by:
Nadav Haklai <nadavh@marvell.com> Signed-off-by:
Narendra Hadke <nhadke@marvell.com> Signed-off-by:
Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20220726091221.12358-1-pali@kernel.org Signed-off-by:
-
Sherry Sun authored
The LPUART can't distinguish between a break signal and a framing error, so need to count the break characters if there is a framing error and received data is zero instead of the parity error. Fixes: 5541a9ba ("serial: fsl_lpuart: handle break and make sysrq work") Reviewed-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20220725050115.12396-1-sherry.sun@nxp.com Signed-off-by:
-
Ben Dooks authored
The info structs are local only to the stm32-usart.c driver and are triggering sparse warnings about being undecalred. Move these into the main driver code and make them static to avoid the following warnings: drivers/tty/serial/stm32-usart.h:42:25: warning: symbol 'stm32f4_info' was not declared. Should it be static? drivers/tty/serial/stm32-usart.h:63:25: warning: symbol 'stm32f7_info' was not declared. Should it be static? drivers/tty/serial/stm32-usart.h:85:25: warning: symbol 'stm32h7_info' was not declared. Should it be static? Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Link: https://lore.kernel.org/r/20220721212430.453192-1-ben-linux@fluff.org Signed-off-by:
-
Shenwei Wang authored
The LPUART hardware doesn't zero out the parity bit on the received characters. This behavior won't impact the use cases of CS8 because the parity bit is the 9th bit which is not currently used by software. But the parity bit for CS7 must be zeroed out by software in order to get the correct raw data. Signed-off-by:
Shenwei Wang <shenwei.wang@nxp.com> Link: https://lore.kernel.org/r/20220714185858.615373-1-shenwei.wang@nxp.com Signed-off-by:
-
Vijaya Krishna Nivarthi authored
tty: serial: qcom-geni-serial: Fix get_clk_div_rate() which otherwise could return a sub-optimal clock rate. In the logic around call to clk_round_rate(), for some corner conditions, get_clk_div_rate() could return an sub-optimal clock rate. Also, if an exact clock rate was not found lowest clock was being returned. Search for suitable clock rate in 2 steps a) exact match or within 2% tolerance b) within 5% tolerance This also takes care of corner conditions. Fixes: c2194bc9 ("tty: serial: qcom-geni-serial: Remove uart frequency table. Instead, find suitable frequency with call to clk_round_rate") Reviewed-by:
Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Link: https://lore.kernel.org/r/1657911343-1909-1-git-send-email-quic_vnivarth@quicinc.com Signed-off-by:
-
Guo Mengqi authored
The error path when get clock frequency fails in bcm2835aux_serial driver does not correctly disable the clock. This flaw was found using a static analysis tool "Hulk Robot", which reported the following warning when analyzing linux-next/master: drivers/tty/serial/8250/8250_bcm2835aux.c: warning: clk_disable_unprepare_missing.cocci The cocci script checks for the existence of clk_disable_unprepare() paired with clk_prepare_enable(). Add the missing clk_disable_unprepare() to the error path. Fixes: fcc446c8 ("serial: 8250_bcm2835aux: Add ACPI support") Reported-by:Hulk Robot <hulkci@huawei.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Guo Mengqi <guomengqi3@huawei.com> Link: https://lore.kernel.org/r/20220715023312.37808-1-guomengqi3@huawei.com Signed-off-by:
-
- Jul 19, 2022
-
-
Tetsuo Handa authored
syzbot reports kernel infoleak at vcs_read() [1], for buffer can be read immediately after resize operation. Initialize buffer using kzalloc(). ---------- #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <linux/fb.h> int main(int argc, char *argv[]) { struct fb_var_screeninfo var = { }; const int fb_fd = open("/dev/fb0", 3); ioctl(fb_fd, FBIOGET_VSCREENINFO, &var); var.yres = 0x21; ioctl(fb_fd, FBIOPUT_VSCREENINFO, &var); return read(open("/dev/vcsu", O_RDONLY), &var, sizeof(var)) == -1; } ---------- Link: https://syzkaller.appspot.com/bug?extid=31a641689d43387f05d3 [1] Cc: stable <stable@vger.kernel.org> Reported-by:syzbot <syzbot+31a641689d43387f05d3@syzkaller.appspotmail.com> Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Link: https://lore.kernel.org/r/4ef053cf-e796-fb5e-58b7-3ae58242a4ad@I-love.SAKURA.ne.jp Signed-off-by:
-
- Jul 16, 2022
-
-
Thomas Bogendoerfer authored
Commit d3164e2f ("MIPS: Remove VR41xx support") removed support for MIPS VR41xx platform, so remove exclusive drivers for this platform, too. Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Link: https://lore.kernel.org/r/20220715140322.135825-1-tsbogend@alpha.franken.de Signed-off-by:
-
- Jul 14, 2022
-
-
Lino Sanfilippo authored
Before the drivers rs485_config() function is called the serial core already ensures that only one of both options RTS on send or RTS after send is set. So remove the concerning sanity check in the driver function to avoid redundancy. Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Lino Sanfilippo <l.sanfilippo@kunbus.com> Link: https://lore.kernel.org/r/20220710164442.2958979-9-LinoSanfilippo@gmx.de Signed-off-by:
-
Lino Sanfilippo authored
Before the drivers rs485_config() function is called the serial core already ensures that only one of both options RTS on send or RTS after send is set. So remove the concerning sanity check in the driver function to avoid redundancy. Reviewed-by:
-
Lino Sanfilippo authored
Currently the documentation claims that a maximum of 1000 msecs is allowed for RTS delays. However nothing actually checks the values read from device tree/ACPI and so it is possible to set much higher values. There is already a maximum of 100 ms enforced for RTS delays that are set via the UART TIOCSRS485 ioctl. To be consistent with that use the same limit for DT/ACPI values. Although this change is visible to userspace the risk of breaking anything when reducing the max delays from 1000 to 100 ms should be very low, since 100 ms is already a very high maximum for delays that are usually rather in the usecs range. Acked-by:
-
Lino Sanfilippo authored
Currently the RTS delays set via device tree are not clamped to a maximum value although the device tree bindings documentation for RS485 claims that only a maximum of 1000 msecs is allowed. So clamp the values to avoid arbitrary high delay settings. However clamp the values to 100 instead of 1000 msecs to be consistent which the maximum that is allowed when setting the delays from userspace via the UART ioctl TIOCSRS485. Signed-off-by:
-
Lino Sanfilippo authored
Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485() into the new function uart_sanitize_serial_rs485_delays(). Reviewed-by:
-
Lino Sanfilippo authored
In serial8250_em485_config() the termination GPIO is set with the uart_port spinlock held. This is an issue if setting the GPIO line can sleep (e.g. since the concerning GPIO expander is connected via SPI or I2C). Fix this by setting the termination line outside of the uart_port spinlock in the serial core and using gpiod_set_value_cansleep() which instead of gpiod_set_value() allows it to sleep. Beside fixing the termination GPIO line setting for the 8250 driver this change also makes setting the termination GPIO generic for all UART drivers. Signed-off-by:
-
Lino Sanfilippo authored
In ar933x_config_rs485() the check for the RTS GPIO is not needed since in case the GPIO is not available at driver init ar933x_no_rs485 is assigned to port->rs485_supported and this function is never called. So remove the check. Also in uart_set_rs485_config() the serial core already assigns the passed serial_rs485 struct to the uart port. So remove the assignment in the drivers rs485_config() function to avoid redundancy. Signed-off-by:
-
Lino Sanfilippo authored
RS485 is not possible without an RTS GPIO regardless of whether RS485 is enabled at boot time or not. So correct the concerning check in the probe() function. Fixes: e849145e ("serial: ar933x: Fill in rs485_supported") Signed-off-by:
-
Doug Berger authored
Commit 9cabe26e ("serial: 8250_bcm7271: UART errors after resuming from S2") prevented an early enabling of RTS during resume, but it did not actively restore the RTS state after resume. Fixes: 9cabe26e ("serial: 8250_bcm7271: UART errors after resuming from S2") Signed-off-by:
Doug Berger <opendmb@gmail.com> Signed-off-by:
-
VAMSHI GAJJELA authored
With PSLVERR_RESP_EN parameter set to 1, the device generates an error response when an attempt to read an empty RBR with FIFO enabled. This happens when LCR writes are ignored when UART is busy. dw8250_check_lcr() in retries to update LCR, invokes dw8250_force_idle() to clear and reset FIFO and eventually reads UART_RX causing the error. Avoid this by not reading RBR/UART_RX when no data is available. Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
VAMSHI GAJJELA <vamshigajjela@google.com> Link: https://lore.kernel.org/r/20220713131722.2316829-1-vamshigajjela@google.com Signed-off-by:
-
Marek Szyprowski authored
S3C2410_UCON is a 32bit register, so it must be read with rd_regl() instead of rd_reg(), otherwise the upper bits will be zeroed. Fix this. Fixes: 72a43046 ("tty: serial: samsung_tty: loopback mode support") Tested-by:
Chanho Park <chanho61.park@samsung.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20220712140745.30362-1-m.szyprowski@samsung.com Signed-off-by:
-
Geert Uytterhoeven authored
The Aspeed Virtual UART is only present on Aspeed BMC platforms. Hence add a dependency on ARCH_ASPEED, to prevent asking the user about this driver when configuring a kernel without Aspeed BMC support. Reviewed-by:
Jeremy Kerr <jk@ozlabs.org> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/259138c372d433005b4871789ef9ee8d15320307.1657528861.git.geert+renesas@glider.be Signed-off-by:
-
Cameron Williams authored
Add support for some of the Brainboxes PCIe (PX) range of serial cards, including the PX-101, PX-235/PX-246, PX-203/PX-257, PX-260/PX-701, PX-310, PX-313, PX-320/PX-324/PX-376/PX-387, PX-335/PX-346, PX-368, PX-420, PX-803 and PX-846. Signed-off-by:
Cameron Williams <cang1@live.co.uk> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/AM5PR0202MB2564669252BDC59BF55A6E87C4879@AM5PR0202MB2564.eurprd02.prod.outlook.com Signed-off-by:
-
- Jul 08, 2022
-
-
Daniel Starke authored
gsmld_poll() currently fails to handle the following corner cases correctly: - remote party closed the associated tty Add the missing checks and map those to EPOLLHUP. Reorder the checks to group them by their reaction. Fixes: e1eaea46 ("tty: n_gsm line discipline") Signed-off-by:
Daniel Starke <daniel.starke@siemens.com> Link: https://lore.kernel.org/r/20220707113223.3685-4-daniel.starke@siemens.com Signed-off-by:
-
Daniel Starke authored
The current implementation constipates all transmission paths during flow control except for flow control frames. However, these may not be located at the beginning of the transmission queue of the control channel. Ensure that flow control frames in the transmission queue for the control channel are always handled even if constipated by skipping through other messages. Fixes: 0af02167 ("tty: n_gsm: fix deadlock and link starvation in outgoing data path") Signed-off-by:
-
Daniel Starke authored
n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.3.3 defines the DM response. There exists no DM command. However, the current implementation incorrectly sends DM as command in case of unexpected UIH frames in gsm_queue(). Correct this behavior by always sending DM as response. Fixes: e1eaea46 ("tty: n_gsm line discipline") Signed-off-by:
-
Daniel Starke authored
n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.7.3 states that the valid range for the maximum number of retransmissions (N2) is from 0 to 255 (both including). gsm_dlci_t1() handles this number incorrectly by performing N2 - 1 retransmission attempts. Setting N2 to zero results in more than 255 retransmission attempts. Fix gsm_dlci_t1() to comply with 3GPP 27.010. Fixes: e1eaea46 ("tty: n_gsm line discipline") Signed-off-by:
-
Ilpo Järvinen authored
When DT provides rs485-term, set termination flag as supported. Reviewed-by:
-
Ilpo Järvinen authored
Embed rs485_supported to uart_port to allow serial core to tweak it as needed. Reviewed-by:
-
Ilpo Järvinen authored
prom_putchar_wait() inputs both mask and val but the callers always set them to the same value. Thus pass only val. Suggested-by:
-
Uwe Kleine-König authored
Some Freescale 8250 implementations have the problem that a single long break results in one irq per character frame time. The code in fsl8250_handle_irq() that is supposed to handle that uses the BI bit in lsr_saved_flags to detect such a situation and then skip the second received character. However it also stores other error bits and so after a single frame error the character received in the next irq handling is passed to the upper layer with a frame error, too. So after a spike on the data line (which is correctly recognized as a frame error) the following valid character is thrown away, because the driver reports a frame error for that one, too. To weaken this problem restrict saving LSR to only the BI bit. Note however that the handling is still broken: - lsr_saved_flags is updated using orig_lsr which is the LSR content for the first received char, but there might be more in the FIFO, so a character is thrown away that is received later and not necessarily the one following the break. - The doubled break might be the 2nd and 3rd char in the FIFO, so the workaround doesn't catch these, because serial8250_rx_chars() doesn't handle the workaround. - lsr_saved_flags might have set UART_LSR_BI at the entry of fsl8250_handle_irq() which doesn't originate from fsl8250_handle_irq()'s "up->lsr_saved_flags |= orig_lsr & UART_LSR_BI;" but from e.g. from serial8250_tx_empty(). - For a long or a short break this isn't about two characters, but more or only a single one. Fixes: 9deaa53a ("serial: add irq handler for Freescale 16550 errata.") Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220704085119.55900-1-u.kleine-koenig@pengutronix.de Signed-off-by:
-
- Jul 01, 2022
-
-
Daniel Starke authored
Within gsm_activate_mux() all timers and locks are initiated before the actual resource for the control channel is allocated. This can lead to race conditions. Allocate the control channel DLCI object first to avoid race conditions. Fixes: e1eaea46 ("tty: n_gsm line discipline") Signed-off-by:
-
Daniel Starke authored
The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc. Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI. BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 </IRQ> <TASK> asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 <e8> 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 08 e8 58 bc 02 00 8b 44 24 08 48 83 c4 10 5d c3 48 63 ff b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 76 10 48 8b 15 fd fc 05 00 f7 d8 64 89 02 48 83 RSP: 002b:00007ffcee77cd18 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007ffcee77cd70 RCX: 00007f3e5e35c15c RDX: 0000000000000100 RSI: 00007ffcee77cd90 RDI: 0000000000000003 RBP: 0000000000000100 R08: 0000000000000000 R09: 7efefefefefefeff R10: 00007f3e5e3bddeb R11: 0000000000000246 R12: 00007ffcee77ce8f R13: 0000000000000001 R14: 000056214404e010 R15: 00007ffcee77cd90 </TASK> Fixes: e1eaea46 ("tty: n_gsm line discipline") Signed-off-by:
-
