- 22 Apr, 2021 17 commits
-
-
Johan Hovold authored
Commit b4d49924 ("tty: serial: bcm63xx: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-11-johan@kernel.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
Commit 1ecc26bd ("atmel_serial: split the interrupt handler") worked around the infamous low_latency behaviour of tty_flip_buffer_push() by dropping and reacquiring the port lock in the tasklet callback. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Cc: Richard Genoud <richard.genoud@gmail.com> Signed-off-by:
-
Johan Hovold authored
Commit 3fa12008 ("tty: serial: arc: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Johan Hovold authored
Commit b16c8e3e ("tty: serial: ar933x: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/Signed-off-by:
-
Johan Hovold authored
Commit 78d34d75 ("tty: serial: apbuart: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/Signed-off-by:
-
Johan Hovold authored
Commit ead76f32 ("ARM: 6763/1: pl011: add optional RX DMA to PL011 v2") added RX DMA support and also reproduced the workaround for the infamous low_latency behaviour of tty_flip_buffer_push() by dropping and reacquiring the port lock during receive processing. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Note that the port lock is also dropped in the PIO path (see pl011_rx_chars), but it is not clear whether this is still needed by the DMA code added by the aforementioned commit. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Russell King <linux@armlinux.org.uk> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Johan Hovold authored
Commit 2389b272 ("[ARM] 4417/1: Serial: Fix AMBA drivers locking") worked around the infamous low_latency behaviour of tty_flip_buffer_push() by simply dropping and reacquiring the port lock in the interrupt handler. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Cc: Russell King <linux@armlinux.org.uk> Signed-off-by:
-
Johan Hovold authored
Commit dd085ed8 ("tty: serial: altera: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Tobias Klauser <tklauser@distanz.ch> Acked-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
-
Johan Hovold authored
Commit 53dd0ba7 ("tty: serial: altera_jtag: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Tobias Klauser <tklauser@distanz.ch> Acked-by:
-
Johan Hovold authored
Commit 67d2bc58 ("Char: mxser_new, fix recursive locking") worked around the infamous low_latency behaviour of tty_flip_buffer_push() by simply dropping and reacquiring the port lock in the interrupt handler. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/lkml/3018694794025219@wsc.cz/T/#m06b04c640a7b6f41afb3d34a4cf29b1df4935d3aReviewed-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Dario Binacchi authored
Data received during half-duplex transmission must be filtered. If the target device responds quickly, emptying the FIFO at the end of the transmission can erase not only the echo characters but also part of the response message. By keeping the receive interrupt enabled even during transmission, it allows you to filter each echo character and only in a number equal to those transmitted. The issue was generated by a target device that started responding 240us later having received a request in communication at 115200bps. Sometimes, some messages received by the target were missing some of the first bytes. Fixes: 3a13884a ("tty/serial: omap: empty the RX FIFO at the end of half-duplex TX") Signed-off-by:
Dario Binacchi <dariobin@libero.it> Link: https://lore.kernel.org/r/20210418094705.27014-1-dariobin@libero.itSigned-off-by:
-
Dario Binacchi authored
There are rs485 transceivers (e.g. MAX13487E/MAX13488E) which automatically disable or enable the driver and receiver to keep the bus in the correct state. In these cases we don't need a GPIO for flow control. Fixes: 4a0ac0f5 ("OMAP: add RS485 support") Signed-off-by:
-
Johan Hovold authored
Use the uart_unlock_and_check_sysrq() helper to defer sysrq processing until receive processing is done and the port lock has been released. This allows cleaning up the console_write() implementation by not having to work around the recursive sysrq case (by dropping locking completely) and also makes the console code work with PREEMPT_RT by no longer relying on local_irq_save(). Reviewed-by: Valentin Caron<valentin.caron@foss.st.com> Signed-off-by:
-
Johan Hovold authored
When DMA is enabled the receive handler runs in a threaded handler, but the primary handler up until very recently neither disabled interrupts in the device or used IRQF_ONESHOT. This would lead to a deadlock if an interrupt comes in while the threaded receive handler is running under the port lock. Commit ad767681 ("serial: stm32: fix a deadlock condition with wakeup event") claimed to fix an unrelated deadlock, but unfortunately also disabled interrupts in the threaded handler. While this prevents the deadlock mentioned in the previous paragraph it also defeats the purpose of using a threaded handler in the first place. Fix this by making the interrupt one-shot and not disabling interrupts in the threaded handler. Note that (receive) DMA must not be used for a console port as the threaded handler could be interrupted while holding the port lock, something which could lead to a deadlock in case an interrupt handler ends up calling printk. Fixes: ad767681 ("serial: stm32: fix a deadlock condition with wakeup event") Fixes: 34891872 ("serial: stm32: adding dma support") Cc: stable@vger.kernel.org # 4.9 Cc: Alexandre TORGUE <alexandre.torgue@st.com> Cc: Gerald Baeza <gerald.baeza@st.com> Reviewed-by: Valentin Caron<valentin.caron@foss.st.com> Signed-off-by:
-
Johan Hovold authored
The uart_unlock_and_check_sysrq() helper can be used to defer processing of sysrq until the interrupt handler has released the port lock and is about to return. Since commit 81e2073c ("genirq: Disable interrupts for force threaded handlers") interrupt handlers that are not explicitly requested as threaded are always called with interrupts disabled and there is no need to save the interrupt state when taking the port lock. Instead of adding another sysrq helper for when the interrupt state has not needlessly been saved, drop the state parameter from uart_unlock_and_check_sysrq() and update its callers to no longer explicitly disable interrupts in their interrupt handlers. Cc: Joel Stanley <joel@jms.id.au> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Colin Ian King authored
The variable count is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Reviewed-by:
Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20210420105718.377086-1-colin.king@canonical.comSigned-off-by:
-
Tetsuo Handa authored
syzbot is reporting hung task due to flood of tty_warn(tty, "%s: tty->count = 1 port count = %d\n", __func__, port->count); message [1], for ioctl(TIOCVHANGUP) prevents tty_port_close() from decrementing port->count due to tty_hung_up_p() == true. ---------- #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <unistd.h> int main(int argc, char *argv[]) { int i; int fd[10]; for (i = 0; i < 10; i++) fd[i] = open("/dev/ttyprintk", O_WRONLY); ioctl(fd[0], TIOCVHANGUP); for (i = 0; i < 10; i++) close(fd[i]); close(open("/dev/ttyprintk", O_WRONLY)); return 0; } ---------- When TTY hangup happens, port->count needs to be reset via "struct tty_operations"->hangup callback. [1] https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6aReported-by:syzbot <syzbot+43e93968b964e369db0b@syzkaller.appspotmail.com> Reported-by:
syzbot <syzbot+3ed715090790806d8b18@syzkaller.appspotmail.com> Tested-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: 24b4b67d ("add ttyprintk driver") Link: https://lore.kernel.org/r/17e0652d-89b7-c8c0-fb53-e7566ac9add4@i-love.sakura.ne.jpSigned-off-by:
-
- 15 Apr, 2021 13 commits
-
-
Ulrich Hecht authored
Since the transition to hrtimers there is no more need to set a minimum RX timeout to work around latency issues. Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Ulrich Hecht <uli+renesas@fpond.eu> Link: https://lore.kernel.org/r/20210415093547.21639-1-uli+renesas@fpond.euSigned-off-by:
-
Greg Kroah-Hartman authored
There are a lot of tty-core-only functions that are listed in include/linux/tty.h. Move them to drivers/tty/tty.h so that no one else can accidentally call them or think that they are public functions. Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-14-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
The flow change and restricted_tty_write() logic is internal to the tty core only, so move it out of the include/linux/tty.h file. Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-12-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
No one calls this outside of the tty_io.c file, so mark this static and do not export the symbol anymore. Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-11-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
Move the TTY_LOCK_* enums and tty_ldisc lock functions out of the global tty.h into the local header file to clean things up. Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-10-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
The functions tty_audit_add_data() and tty_audit_tiocsti() are local to the tty core code, and do not need to be in a "kernel-wide" header file so move them to drivers/tty/tty.h Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-9-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
No one is calling this macro, and no one should, so remove it from the .h file. Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
There are a number of functions and #defines in include/linux/tty.h that do not belong there as they are private to the tty core code. Create an initial drivers/tty/tty.h file and copy the odd "tty logging" macros into it to seed the file with some initial things that we know nothing outside of the tty core should be calling. Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-2-gregkh@linuxfoundation.orgSigned-off-by:
-
Hillf Danton authored
Add the error path for registering tty devices and roll back in case of error in bid to avoid the UAF like the below one reported. Plus syzbot reported general protection fault in cdev_del() on Sep 24, 2020 and both cases are down to the kobject_put() in tty_cdev_add(). ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 8923 at lib/refcount.c:28 refcount_warn_saturate+0x1cf/0x210 -origin/lib/refcount.c:28 Modules linked in: CPU: 1 PID: 8923 Comm: executor Not tainted 5.12.0-rc5+ #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x1cf/0x210 -origin/lib/refcount.c:28 Code: 4f ff ff ff e8 32 fa b5 fe 48 c7 c7 3d f8 f6 86 e8 d6 ab c6 fe c6 05 7c 34 67 04 01 48 c7 c7 68 f8 6d 86 31 c0 e8 81 2e 9d fe <0f> 0b e9 22 ff ff ff e8 05 fa b5 fe 48 c7 c7 3e f8 f6 86 e8 a9 ab RSP: 0018:ffffc90001633c60 EFLAGS: 00010246 RAX: 15d08b2e34b77800 RBX: 0000000000000003 RCX: ffff88804c056c80 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000003 R08: ffffffff813767aa R09: 0001ffffffffffff R10: 0001ffffffffffff R11: ffff88804c056c80 R12: ffff888040b7d000 R13: ffff88804c206938 R14: ffff88804c206900 R15: ffff888041b18488 FS: 00000000022c9940(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9f9b122008 CR3: 0000000044b4b000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: __refcount_sub_and_test -origin/./include/linux/refcount.h:283 [inline] __refcount_dec_and_test -origin/./include/linux/refcount.h:315 [inline] refcount_dec_and_test -origin/./include/linux/refcount.h:333 [inline] kref_put -origin/./include/linux/kref.h:64 [inline] kobject_put+0x17b/0x180 -origin/lib/kobject.c:753 cdev_del+0x4b/0x50 -origin/fs/char_dev.c:597 tty_unregister_device+0x99/0xd0 -origin/drivers/tty/tty_io.c:3343 gsmld_detach_gsm -origin/drivers/tty/n_gsm.c:2409 [inline] gsmld_close+0x6c/0x140 -origin/drivers/tty/n_gsm.c:2478 tty_ldisc_close -origin/drivers/tty/tty_ldisc.c:488 [inline] tty_ldisc_kill -origin/drivers/tty/tty_ldisc.c:636 [inline] tty_ldisc_release+0x1b6/0x400 -origin/drivers/tty/tty_ldisc.c:809 tty_release_struct+0x19/0xb0 -origin/drivers/tty/tty_io.c:1714 tty_release+0x9ad/0xa00 -origin/drivers/tty/tty_io.c:1885 __fput+0x260/0x4e0 -origin/fs/file_table.c:280 ____fput+0x11/0x20 -origin/fs/file_table.c:313 task_work_run+0x8e/0x110 -origin/kernel/task_work.c:140 tracehook_notify_resume -origin/./include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop -origin/kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x16b/0x1a0 -origin/kernel/entry/common.c:208 __syscall_exit_to_user_mode_work -origin/kernel/entry/common.c:290 [inline] syscall_exit_to_user_mode+0x20/0x40 -origin/kernel/entry/common.c:301 do_syscall_64+0x45/0x80 -origin/arch/x86/entry/common.c:56 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com Reported-and-tested-by:
Hao Sun <sunhao.th@gmail.com> Signed-off-by:
Hillf Danton <hdanton@sina.com> Link: https://lore.kernel.org/r/20210412035758.1974-1-hdanton@sina.comSigned-off-by:
-
Zev Weiss authored
These correspond to the existing lpc_address, sirq, and sirq_polarity sysfs attributes; the second element of aspeed,lpc-interrupts provides a replacement for the deprecated aspeed,sirq-polarity-sense property. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20210412034712.16778-5-zev@bewilderbeest.netSigned-off-by:
-
Zev Weiss authored
These allow describing all the Aspeed VUART attributes currently available via sysfs. aspeed,lpc-interrupts provides a replacement for the deprecated aspeed,sirq-polarity-sense property. Reviewed-by:
Andrew Jeffery <andrew@aj.id.au> Signed-off-by:
-
Zev Weiss authored
This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions out of the sysfs store functions in preparation for adding DT properties that will be poking the same registers. While we're at it, these functions now provide some basic bounds-checking on their arguments. Reviewed-by: -
Zev Weiss authored
This property ties SIRQ polarity to SCU register bits that don't necessarily have any direct relationship to it; the only use of it was removed in commit c82bf6e1 ("ARM: aspeed: g5: Do not set sirq polarity"). Reviewed-by:
Joel Stanley <joel@jms.id.au> Acked-by:
-
- 10 Apr, 2021 10 commits
-
-
Yu Kuai authored
The sparse tool complains as follows: drivers/tty/hvc/hvc_udbg.c:20:19: warning: symbol 'hvc_udbg_dev' was not declared. Should it be static? This symbol is not used outside of hvc_udbg.c, so this commit marks it static. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Link: https://lore.kernel.org/r/20210407125826.4139130-1-yukuai3@huawei.comSigned-off-by:
-
Johan Hovold authored
Commit 30004ac9 ("tty: add tty_struct->dev pointer to corresponding device instance") added a struct device pointer field to struct tty_struct which was populated with the corresponding tty class device during initialisation. Unfortunately, not all ttys have a class device (e.g. pseudoterminals and serdev) in which case the device pointer will be set to NULL, something which have bit driver authors over the years. In retrospect perhaps this field should never have been added, but let's at least document the current behaviour. Signed-off-by:
-
Bixuan Cui authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by:
Bixuan Cui <cuibixuan@huawei.com> Link: https://lore.kernel.org/r/20210410035048.11466-1-cuibixuan@huawei.comSigned-off-by:
-
Krzysztof Kozlowski authored
Include the generic serial.yaml dtschema so the child node like "bluetooth" will be properly matched: arch/arm/boot/dts/exynos4210-universal_c210.dt.yaml: serial@13800000: 'bluetooth' does not match any of the regexes: 'pinctrl-[0-9]+' Reviewed-by:Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20210409172027.11296-1-krzysztof.kozlowski@canonical.comSigned-off-by:
-
Johan Hovold authored
Drivers can return -ENOIOCTLCMD when an ioctl is not recognised to tell the upper layers to continue looking for a handler. This is not the case for the RS485 and ISO7816 ioctls whose handlers should return -ENOTTY directly in case a serial driver does not implement the corresponding methods. Fixes: a5f276f1 ("serial_core: Handle TIOC[GS]RS485 ioctls.") Fixes: ad8c0eaa ("tty/serial_core: add ISO7816 infrastructure") Signed-off-by:
-
Johan Hovold authored
Since commit 5099d234 ("serial_core: switch to ->[sg]et_serial()") the serial structure passed to uart_get_info() has already have been cleared by the tty layer so drop the redundant memset. Signed-off-by:
-
Johan Hovold authored
Callout devices are long-gone, but the ASYNC_SPLIT_TERMIOS flag was never added to the deprecation mask. Add it so that a warning is printed if it is ever used. Fixes: 8a8ae62f ("tty: warn on deprecated serial flags") Signed-off-by:
-
Johan Hovold authored
Factor out the deprecated serial flags handling and tty-operation check shared with the compat TIOCSSERIAL handler. Signed-off-by:
-
Johan Hovold authored
Use pr_warn_ratelimited() when warning about deprecated serial flags instead of open coding. Signed-off-by:
-
Johan Hovold authored
Drivers should return -ENOTTY ("Inappropriate I/O control operation") when an ioctl isn't supported, while -EINVAL is used for invalid arguments. Support for termiox was added by commit 1d65b4a0 ("tty: Add termiox") in 2008 but no driver support ever followed and it was recently ripped out by commit e0efb316 ("tty: Remove dead termiox code"). Fix the return value for the unsupported termiox ioctls, which have always returned -EINVAL, by explicitly returning -ENOTTY rather than removing them completely and falling back to the default unrecognised- ioctl handling. Fixes: 1d65b4a0 ("tty: Add termiox") Signed-off-by:
-
