summaryrefslogtreecommitdiff
path: root/drivers/tty/serial/serial_core.c
AgeCommit message (Collapse)AuthorFilesLines
2022-04-08serial: 8250: fix XOFF/XON sending when DMA is usedIlpo Järvinen1-0/+14
[ Upstream commit f58c252e30cf74f68b0054293adc03b5923b9f0e ] When 8250 UART is using DMA, x_char (XON/XOFF) is never sent to the wire. After this change, x_char is injected correctly. Create uart_xchar_out() helper for sending the x_char out and accounting related to it. It seems that almost every driver does these same steps with x_char. Except for 8250, however, almost all currently lack .serial_out so they cannot immediately take advantage of this new helper. The downside of this patch is that it might reintroduce the problems some devices faced with mixed DMA/non-DMA transfer which caused revert f967fc8f165f (Revert "serial: 8250_dma: don't bother DMA with small transfers"). However, the impact should be limited to cases with XON/XOFF (that didn't work with DMA capable devices to begin with so this problem is not very likely to cause a major issue, if any at all). Fixes: 9ee4b83e51f74 ("serial: 8250: Add support for dmaengine") Reported-by: Gilles Buloz <gilles.buloz@kontron.com> Tested-by: Gilles Buloz <gilles.buloz@kontron.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220314091432.4288-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27serial: Fix incorrect rs485 polarity on uart openLukas Wunner1-2/+2
commit d3b3404df318504ec084213ab1065b73f49b0f1d upstream. Commit a6845e1e1b78 ("serial: core: Consider rs485 settings to drive RTS") sought to deassert RTS when opening an rs485-enabled uart port. That way, the transceiver does not occupy the bus until it transmits data. Unfortunately, the commit mixed up the logic and *asserted* RTS instead of *deasserting* it: The commit amended uart_port_dtr_rts(), which raises DTR and RTS when opening an rs232 port. "Raising" actually means lowering the signal that's coming out of the uart, because an rs232 transceiver not only changes a signal's voltage level, it also *inverts* the signal. See the simplified schematic in the MAX232 datasheet for an example: https://www.ti.com/lit/ds/symlink/max232.pdf So, to raise RTS on an rs232 port, TIOCM_RTS is *set* in port->mctrl and that results in the signal being driven low. In contrast to rs232, the signal level for rs485 Transmit Enable is the identity, not the inversion: If the transceiver expects a "high" RTS signal for Transmit Enable, the signal coming out of the uart must also be high, so TIOCM_RTS must be *cleared* in port->mctrl. The commit did the exact opposite, but it's easy to see why given the confusing semantics of rs232 and rs485. Fix it. Fixes: a6845e1e1b78 ("serial: core: Consider rs485 settings to drive RTS") Cc: stable@vger.kernel.org # v4.14+ Cc: Rafael Gago Castano <rgc@hms.se> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Su Bao Cheng <baocheng.su@siemens.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/9395767847833f2f3193c49cde38501eeb3b5669.1639821059.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27serial: core: Keep mctrl register state and cached copy in syncLukas Wunner1-1/+2
[ Upstream commit 93a770b7e16772530196674ffc79bb13fa927dc6 ] struct uart_port contains a cached copy of the Modem Control signals. It is used to skip register writes in uart_update_mctrl() if the new signal state equals the old signal state. It also avoids a register read to obtain the current state of output signals. When a uart_port is registered, uart_configure_port() changes signal state but neglects to keep the cached copy in sync. That may cause a subsequent register write to be incorrectly skipped. Fix it before it trips somebody up. This behavior has been present ever since the serial core was introduced in 2002: https://git.kernel.org/history/history/c/33c0d1b0c3eb So far it was never an issue because the cached copy is initialized to 0 by kzalloc() and when uart_configure_port() is executed, at most DTR has been set by uart_set_options() or sunsu_console_setup(). Therefore, a stable designation seems unnecessary. Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/bceeaba030b028ed810272d55d5fc6f3656ddddb.1641129752.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-08serial: 8250: Fix RTS modem control while in rs485 modeLukas Wunner1-0/+5
commit f85e04503f369b3f2be28c83fc48b74e19936ebc upstream. Commit f45709df7731 ("serial: 8250: Don't touch RTS modem control while in rs485 mode") sought to prevent user space from interfering with rs485 communication by ignoring a TIOCMSET ioctl() which changes RTS polarity. It did so in serial8250_do_set_mctrl(), which turns out to be too deep in the call stack: When a uart_port is opened, RTS polarity is set by the rs485-aware function uart_port_dtr_rts(). It calls down to serial8250_do_set_mctrl() and that particular RTS polarity change should *not* be ignored. The user-visible result is that on 8250_omap ports which use rs485 with inverse polarity (RTS bit in MCR register is 1 to receive, 0 to send), a newly opened port initially sets up RTS for sending instead of receiving. That's because omap_8250_startup() sets the cached value up->mcr to 0 and omap_8250_restore_regs() subsequently writes it to the MCR register. Due to the commit, serial8250_do_set_mctrl() preserves that incorrect register value: do_sys_openat2 do_filp_open path_openat vfs_open do_dentry_open chrdev_open tty_open uart_open tty_port_open uart_port_activate uart_startup uart_port_startup serial8250_startup omap_8250_startup # up->mcr = 0 uart_change_speed serial8250_set_termios omap_8250_set_termios omap_8250_restore_regs serial8250_out_MCR # up->mcr written tty_port_block_til_ready uart_dtr_rts uart_port_dtr_rts serial8250_set_mctrl omap8250_set_mctrl serial8250_do_set_mctrl # mcr[1] = 1 ignored Fix by intercepting RTS changes from user space in uart_tiocmset() instead. Link: https://lore.kernel.org/linux-serial/20211027111644.1996921-1-baocheng.su@siemens.com/ Fixes: f45709df7731 ("serial: 8250: Don't touch RTS modem control while in rs485 mode") Cc: Chao Zeng <chao.zeng@siemens.com> Cc: stable@vger.kernel.org # v5.7+ Reported-by: Su Bao Cheng <baocheng.su@siemens.com> Reported-by: Jan Kiszka <jan.kiszka@siemens.com> Tested-by: Su Bao Cheng <baocheng.su@siemens.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/21170e622a1aaf842a50b32146008b5374b3dd1d.1637596432.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-08serial: core: fix transmit-buffer reset and memleakJohan Hovold1-1/+12
commit 00de977f9e0aa9760d9a79d1e41ff780f74e3424 upstream. Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()"). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")). Link: https://lore.kernel.org/r/319321886d97c456203d5c6a576a5480d07c3478.1635781688.git.baruch@tkos.co.il Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") Cc: stable@vger.kernel.org # 4.9 Cc: Rob Herring <robh@kernel.org> Reported-by: Baruch Siach <baruch@tkos.co.il> Tested-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211108085431.12637-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18serial: core: Fix initializing and restoring termios speedPali Rohár1-2/+14
commit 027b57170bf8bb6999a28e4a5f3d78bf1db0f90c upstream. Since commit edc6afc54968 ("tty: switch to ktermios and new framework") termios speed is no longer stored only in c_cflag member but also in new additional c_ispeed and c_ospeed members. If BOTHER flag is set in c_cflag then termios speed is stored only in these new members. Therefore to correctly restore termios speed it is required to store also ispeed and ospeed members, not only cflag member. In case only cflag member with BOTHER flag is restored then functions tty_termios_baud_rate() and tty_termios_input_baud_rate() returns baudrate stored in c_ospeed / c_ispeed member, which is zero as it was not restored too. If reported baudrate is invalid (e.g. zero) then serial core functions report fallback baudrate value 9600. So it means that in this case original baudrate is lost and kernel changes it to value 9600. Simple reproducer of this issue is to boot kernel with following command line argument: "console=ttyXXX,86400" (where ttyXXX is the device name). For speed 86400 there is no Bnnn constant and therefore kernel has to represent this speed via BOTHER c_cflag. Which means that speed is stored only in c_ospeed and c_ispeed members, not in c_cflag anymore. If bootloader correctly configures serial device to speed 86400 then kernel prints boot log to early console at speed speed 86400 without any issue. But after kernel starts initializing real console device ttyXXX then speed is changed to fallback value 9600 because information about speed was lost. This patch fixes above issue by storing and restoring also ispeed and ospeed members, which are required for BOTHER flag. Fixes: edc6afc54968 ("[PATCH] tty: switch to ktermios and new framework") Cc: stable@vger.kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20211002130900.9518-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27tty: drop put_tty_driverJiri Slaby1-2/+2
put_tty_driver() is an alias for tty_driver_kref_put(). There is no need for two exported identical functions, therefore switch all users of old put_tty_driver() to new tty_driver_kref_put() and remove the former for good. Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jeff Dike <jdike@addtoit.com> Cc: Richard Weinberger <richard@nod.at> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Cc: Jens Taprogge <jens.taprogge@taprogge.org> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Scott Branden <scott.branden@broadcom.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David Lin <dtwlin@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: David Sterba <dsterba@suse.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Oliver Neukum <oneukum@suse.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Acked-by: Alex Elder <elder@linaro.org> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: David Sterba <dsterba@suse.com> Acked-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210723074317.32690-8-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27tty: stop using alloc_tty_driverJiri Slaby1-3/+5
alloc_tty_driver was deprecated by tty_alloc_driver in commit 7f0bc6a68ed9 (TTY: pass flags to alloc_tty_driver) in 2012. I never got into eliminating alloc_tty_driver until now. So we still have two functions for allocating drivers which might be confusing. So get rid of alloc_tty_driver uses to eliminate it for good in the next patch. Note we need to switch return value checking as tty_alloc_driver uses ERR_PTR. And flags are now a parameter of tty_alloc_driver. Cc: Richard Henderson <rth@twiddle.net>(odd fixer:ALPHA PORT) Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: Jeff Dike <jdike@addtoit.com> Cc: Richard Weinberger <richard@nod.at> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Cc: Jens Taprogge <jens.taprogge@taprogge.org> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: David Sterba <dsterba@suse.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Oliver Neukum <oneukum@suse.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Johan Hovold <johan@kernel.org> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Acked-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: David Sterba <dsterba@suse.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210723074317.32690-5-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-21serial: core: Report magic multiplier extra baud ratesMaciej W. Rozycki1-0/+8
Report extra baud rates supported above the base rate for ports with the UPF_MAGIC_MULTIPLIER property, so that people have a way to find out that they can be used with their system, e.g.: Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled printk: console [ttyS0] disabled serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A serial8250.0: ttyS0 extra baud rates supported: 230400, 460800 printk: console [ttyS0] enabled printk: bootconsole [uart8250] disabled serial8250.0: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A serial8250.0: ttyS1 extra baud rates supported: 230400, 460800 serial8250.0: ttyS2 at MMIO 0x1f000900 (irq = 20, base_baud = 230400) is a 16550A Otherwise there is no clear way to figure this out, as the feature is only reported as an obscure TTY flag in bit 16: $ cat /sys/class/tty/ttyS[0-2]/flags 0x10010040 0x10010040 0x90000040 $ Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106260334170.37803@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-15tty: make tty_get_{char,frame}_size availableJiri Slaby1-27/+3
Many tty drivers contain code to compute bits count depending on termios cflags. So extract this code from serial core to two separate tty helper functions: * tty_get_char_size -- only size of a character, without flags, * tty_get_frame_size -- complete size of a frame including flags. In the next patch, calls to these new functions replace many copies of this code. Note that we accept only cflag as a parameter. That's because some callers like pch_uart_startup or sunsab_console_setup don't have at hand termios which we could pass around. Cc: Joe Perches <joe@perches.com> Cc: Johan Hovold <johan@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210610090247.2593-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-31Merge 5.13-rc4 into tty-nextGreg Kroah-Hartman1-3/+5
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-20tty/serial: clean up uart_match_portJiri Slaby1-7/+9
* make parameters const (as they are only read) * return bool (as comparison results are returned) * add \n before final return Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210519072153.3859-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-20serial: drop irq-flags initialisationsJohan Hovold1-2/+2
There's no need to initialise irq-flags variables before saving the interrupt state. Drop the redundant initialisations from drivers that got this wrong. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210519092541.10137-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13tty: make tty_operations::chars_in_buffer return uintJiri Slaby1-2/+2
tty_operations::chars_in_buffer is another hook which is expected to return values >= 0. So make it explicit by the return type too -- use unsigned int. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com> Acked-by: David Sterba <dsterba@suse.com> Cc: Jeff Dike <jdike@addtoit.com> Cc: Richard Weinberger <richard@nod.at> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Cc: Jens Taprogge <jens.taprogge@taprogge.org> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David Lin <dtwlin@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Oliver Neukum <oneukum@suse.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Link: https://lore.kernel.org/r/20210505091928.22010-27-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: core: fix suspicious security_locked_down() callOndrej Mosnacek1-3/+5
The commit that added this check did so in a very strange way - first security_locked_down() is called, its value stored into retval, and if it's nonzero, then an additional check is made for (change_irq || change_port), and if this is true, the function returns. However, if the goto exit branch is not taken, the code keeps the retval value and continues executing the function. Then, depending on whether uport->ops->verify_port is set, the retval value may or may not be reset to zero and eventually the error value from security_locked_down() may abort the function a few lines below. I will go out on a limb and assume that this isn't the intended behavior and that an error value from security_locked_down() was supposed to abort the function only in case (change_irq || change_port) is true. Note that security_locked_down() should be called last in any series of checks, since the SELinux implementation of this hook will do a check against the policy and generate an audit record in case of denial. If the operation was to carry on after calling security_locked_down(), then the SELinux denial record would be bogus. See commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") for how SELinux implements this hook. Fixes: 794edf30ee6c ("lockdown: Lock down TIOCSSERIAL") Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210507115719.140799-1-omosnace@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13tty: make tty_operations::write_room return uintJiri Slaby1-2/+2
Line disciplines expect a positive value or zero returned from tty->ops->write_room (invoked by tty_write_room). So make this assumption explicit by using unsigned int as a return value. Both of tty->ops->write_room and tty_write_room. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Acked-by: Alex Elder <elder@linaro.org> Acked-by: Max Filippov <jcmvbkbc@gmail.com> # xtensa Acked-by: David Sterba <dsterba@suse.com> Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: Jeff Dike <jdike@addtoit.com> Cc: Richard Weinberger <richard@nod.at> Cc: Chris Zankel <chris@zankel.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Cc: Jens Taprogge <jens.taprogge@taprogge.org> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Scott Branden <scott.branden@broadcom.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David Lin <dtwlin@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Oliver Neukum <oneukum@suse.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Link: https://lore.kernel.org/r/20210505091928.22010-23-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-10serial: core: return early on unsupported ioctlsJohan Hovold1-3/+3
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: a5f276f10ff7 ("serial_core: Handle TIOC[GS]RS485 ioctls.") Fixes: ad8c0eaa0a41 ("tty/serial_core: add ISO7816 infrastructure") Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407095208.31838-9-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-10serial: core: drop redundant TIOCGSERIAL memsetJohan Hovold1-2/+0
Since commit 5099d234a52a ("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 <johan@kernel.org> Link: https://lore.kernel.org/r/20210407095208.31838-8-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-09serial: core: Remove BUG_ON(in_interrupt()) checkAhmed S. Darwish1-4/+4
The usage of in_interrupt() in drivers is phased out for various reasons. In both exported functions where BUG_ON(in_interrupt()) is invoked, there is a mutex_lock() afterwards. mutex_lock() contains a might_sleep() which will already trigger a stack trace if the target functions is called from atomic context. Remove the BUG_ON() and add a "Context: " in the kernel-doc instead. Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20210208181615.381861-3-bigeasy@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-07tty_port: drop last traces of low_latencyJiri Slaby1-3/+0
The main purpose of tty_port::low_latency was removed in commit a9c3f68f3cd8 (tty: Fix low_latency BUG) back in 2014. It was left in place for drivers as an optional tune knob. But only one driver has been using it until the previous commit. So remove this misconcept completely, given there are no users. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210105120239.28031-11-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-09serial_core: Check for port state when tty is in error stateAlexey Kardashevskiy1-0/+4
At the moment opening a serial device node (such as /dev/ttyS3) succeeds even if there is no actual serial device behind it. Reading/writing/ioctls fail as expected because the uart port is not initialized (the type is PORT_UNKNOWN) and the TTY_IO_ERROR error state bit is set fot the tty. However setting line discipline does not have these checks 8250_port.c (8250 is the default choice made by univ8250_console_init()). As the result of PORT_UNKNOWN, uart_port::iobase is NULL which a platform translates onto some address accessing which produces a crash like below. This adds tty_port_initialized() to uart_set_ldisc() to prevent the crash. Found by syzkaller. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Link: https://lore.kernel.org/r/20201203055834.45838-1-aik@ozlabs.ru Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-21Merge 5.9.0-rc6 into tty-nextGreg Kroah-Hartman1-24/+20
We need the tty/serial fixes in here and this resolves a merge issue in the 8250 driver. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: core: fix console port-lock regressionJohan Hovold1-17/+15
Fix the port-lock initialisation regression introduced by commit a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") by making sure that the lock is again initialised during console setup. The console may be registered before the serial controller has been probed in which case the port lock needs to be initialised during console setup by a call to uart_set_options(). The console-detach changes introduced a regression in several drivers by effectively removing that initialisation by not initialising the lock when the port is used as a console (which is always the case during console setup). Add back the early lock initialisation and instead use a new console-reinit flag to handle the case where a console is being re-attached through sysfs. The question whether the console-detach interface should have been added in the first place is left for another discussion. Note that the console-enabled check in uart_set_options() is not redundant because of kgdboc, which can end up reinitialising an already enabled console (see commit 42b6a1baa3ec ("serial_core: Don't re-initialize a previously initialized spinlock.")). Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") Cc: stable <stable@vger.kernel.org> # 5.7 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200909143101.15389-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: core: fix port-lock initialisationJohan Hovold1-8/+6
Commit f743061a85f5 ("serial: core: Initialise spin lock before use in uart_configure_port()") tried to work around a breakage introduced by commit a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") by adding a second initialisation of the port lock when registering the port. As reported by the build robots [1], this doesn't really solve the regression introduced by the console-detach changes and also adds a second redundant initialisation of the lock for normal ports. Start cleaning up this mess by removing the redundant initialisation and making sure that the port lock is again initialised once-only for ports that aren't already in use as a console. [1] https://lore.kernel.org/r/20200802054852.GR23458@shao2-debian Fixes: f743061a85f5 ("serial: core: Initialise spin lock before use in uart_configure_port()") Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") Cc: stable <stable@vger.kernel.org> # 5.7 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200909143101.15389-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04serial: core: Simplify with dev_err_probe()Krzysztof Kozlowski1-3/+1
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and the error value gets printed. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/20200901153100.18827-2-krzk@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-31Merge 5.9-rc3 into tty-nextGreg Kroah-Hartman1-1/+1
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-28serial: core: don't use snprintf() for formatting sysfs attrsAlex Dewar1-13/+13
As per the documentation (Documentation/filesystems/sysfs.rst), snprintf() should not be used for formatting values returned by sysfs. For all of the instances in serial_core.c, we know that the string will be <PAGE_SIZE in length, so just use sprintf(). Issue identified by Coccinelle. Signed-off-by: Alex Dewar <alex.dewar90@gmail.com> Link: https://lore.kernel.org/r/20200824223932.27709-1-alex.dewar90@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-24treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva1-1/+1
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-07-21serial: core: Fix Coding StyleTamseel Shams1-1/+3
This patch fixes the following checkpatch error and warning: 1. space required after ',' 2. Missing a blank line after declarations Signed-off-by: Tamseel Shams <m.shams@samsung.com> Link: https://lore.kernel.org/r/20200716115438.9967-1-m.shams@samsung.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-20Merge 5.8-rc6 into tty-nextGreg Kroah-Hartman1-98/+17
We need the serial/tty fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-10serial: core: Initialise spin lock before use in uart_configure_port()Andy Shevchenko1-2/+14
The comment near to uart_port_spin_lock_init() says: Ensure that the serial console lock is initialised early. If this port is a console, then the spinlock is already initialised. and there is nothing about enabled or disabled consoles. The commit a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") made a change, which follows the comment, and also to prevent reinitialisation of the lock in use, when user detaches and attaches back the same console device. But this change discovers another issue, that uart_add_one_port() tries to access a spin lock that now may be uninitialised. This happens when a driver expects the serial core to register a console on its behalf. In this case we must initialise a spin lock before use. Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") Reported-by: Marc Zyngier <maz@kernel.org> Reported-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: Anatoly Pugachev <matorola@gmail.com> Acked-by: Marc Zyngier <maz@kernel.org> Tested-by: Tony Lindgren <tony@atomide.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20200706214903.56148-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-27serial: core: fix sysrq overhead regressionJohan Hovold1-97/+2
Commit 8e20fc391711 ("serial_core: Move sysrq functions from header file") converted the inline sysrq helpers to exported functions which are now called for every received character, interrupt and break signal also on systems without CONFIG_MAGIC_SYSRQ_SERIAL instead of being optimised away by the compiler. Inlining these helpers again also avoids the function call overhead when CONFIG_MAGIC_SYSRQ_SERIAL is enabled (e.g. when the port is not used as a console). Fixes: 8e20fc391711 ("serial_core: Move sysrq functions from header file") Cc: Dmitry Safonov <0x7f454c46@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Cc: stable <stable@vger.kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://lore.kernel.org/r/20200610152232.16925-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-27Revert "serial: core: Refactor uart_unlock_and_check_sysrq()"Johan Hovold1-10/+13
This reverts commit da9a5aa3402db0ff3b57216d8dbf2478e1046cae. In order to ease backporting a fix for a sysrq regression, revert this rewrite which was since added on top. The other sysrq helpers now bail out early when sysrq is not enabled; it's better to keep that pattern here as well. Note that the __releases() attribute won't be needed after the follow-on fix either. Fixes: da9a5aa3402d ("serial: core: Refactor uart_unlock_and_check_sysrq()") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200610152232.16925-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-27serial: core: drop unnecessary gpio includeJohan Hovold1-0/+1
Drop the recently added gpio include from the serial-core header in favour of a forward declaration and instead include the gpio header only where needed. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20200610155121.14014-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-27tty/serial: fix serial_core.c kernel-doc warningsRandy Dunlap1-2/+1
Fix kernel-doc warnings in serial_core.c: ../drivers/tty/serial/serial_core.c:3300: warning: Function parameter or member 'port' not described in 'uart_get_rs485_mode' ../drivers/tty/serial/serial_core.c:3300: warning: Excess function parameter 'dev' description in 'uart_get_rs485_mode' ../drivers/tty/serial/serial_core.c:3300: warning: Excess function parameter 'rs485conf' description in 'uart_get_rs485_mode' Fixes: c150c0f362c1 ("serial: Allow uart_get_rs485_mode() to return errno") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Lukas Wunner <lukas@wunner.de> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-serial@vger.kernel.org Link: https://lore.kernel.org/r/e170db8e-5c8b-27ac-79a4-81b96ac0ca2d@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-29serial: 8250: Support rs485 bus termination GPIOLukas Wunner1-0/+16
Commit e8759ad17d41 ("serial: uapi: Add support for bus termination") introduced the ability to enable rs485 bus termination from user space. So far the feature is only used by a single driver, 8250_exar.c, using a hardcoded GPIO pin specific to Siemens IOT2040 products. Provide for a more generic solution by allowing specification of an rs485 bus termination GPIO pin in the device tree: Amend the serial core to retrieve the GPIO from the device tree (or ACPI table) and amend the default ->rs485_config() callback for 8250 drivers to change the GPIO on request from user space. Perhaps 8250_exar.c can be converted to the generic approach in a follow-up patch. Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Link: https://lore.kernel.org/r/94c6c800d1ca9fa04766dd1d43a8272c5ad4bedd.1589811297.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-15serial: Allow uart_get_rs485_mode() to return errnoLukas Wunner1-1/+5
We're about to amend uart_get_rs485_mode() to support a GPIO pin for rs485 bus termination. Retrieving the GPIO descriptor may fail, so allow uart_get_rs485_mode() to return an errno and change all callers to check for failure. The GPIO descriptor is going to be stored in struct uart_port. Pass that struct to uart_get_rs485_mode() in lieu of a struct device and struct serial_rs485, both of which are directly accessible from struct uart_port. A few drivers call uart_get_rs485_mode() before setting the struct device pointer in struct uart_port. Shuffle those calls around where necessary. [Heiko Stuebner did the ar933x_uart.c portion, hence his Signed-off-by.] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/271e814af4b0db3bffbbb74abf2b46b75add4516.1589285873.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-17serial: core: Allow detach and attach serial device for consoleAndy Shevchenko1-4/+56
In the future we would like to disable power management on the serial devices used as kernel consoles to avoid weird behaviour in some cases. However, disabling PM may prevent system to go to deep sleep states, which in its turn leads to the higher power consumption. Tony Lindgren proposed a work around, i.e. allow user to detach such consoles to make PM working again. In case user wants to see what's going on, it also provides a mechanism to attach console back. Link: https://lists.openwall.net/linux-kernel/2018/09/29/65 Suggested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200217114016.49856-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12serial: core: Refactor uart_unlock_and_check_sysrq()Andy Shevchenko1-13/+10
Refactor uart_unlock_and_check_sysrq() to: - explicitly show that we release a port lock which makes static analyzers happy: CHECK drivers/tty/serial/serial_core.c .../serial_core.c:3290:17: warning: context imbalance in 'uart_unlock_and_check_sysrq' - unexpected unlock - use flags instead of irqflags to avoid confusion with IRQ flags - provide one return point - be more compact Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://lore.kernel.org/r/20200310174337.74109-4-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12serial: core: Use uart_console() helper in SysRq codeAndy Shevchenko1-7/+5
Use uart_console() helper in SysRq code instead of open coded variant. This eliminates the conditional entirely for SERIAL_CORE_CONSOLE=n case. While here, refactor the conditional to be more compact. Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200310174337.74109-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12serial: core: Print escaped SysRq Magic sequence if enabledAndy Shevchenko1-1/+4
It is useful to see on the serial console the magic sequence itself to enable SysRq without rummaging source code. Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200310174337.74109-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12serial: core: Use string length for SysRq magic sequenceAndy Shevchenko1-3/+4
Compiler is not happy about using ARRAY_SIZE() in comparison to smaller type: CC drivers/tty/serial/serial_core.o .../serial_core.c: In function ‘uart_try_toggle_sysrq’: .../serial_core.c:3222:24: warning: comparison is always false due to limited range of data type [-Wtype-limits] 3222 | if (++port->sysrq_seq < (ARRAY_SIZE(sysrq_toggle_seq) - 1)) { | ^ Looking at the code it appears that there is an additional weirdness, i.e. use ARRAY_SIZE() against simple string literal. Yes, the idea probably was to allow '\0' in the sequence, but it's impractical: kernel configuration won't accept it to begin with followed by a comment about '\0' before comparison in question. Drop all these by switching to strlen() and convert code accordingly. Note, GCC seems clever enough to calculate string length at compile time. Fixes: 68af43173d3f ("serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE") Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200310174337.74109-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-07serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCEDmitry Safonov1-7/+68
Many embedded boards have a disconnected TTL level serial which can generate some garbage that can lead to spurious false sysrq detects. Currently, sysrq can be either completely disabled for serial console or always disabled (with CONFIG_MAGIC_SYSRQ_SERIAL), since commit 732dbf3a6104 ("serial: do not accept sysrq characters via serial port") At Arista, we have such boards that can generate BREAK and random garbage. While disabling sysrq for serial console would solve the problem with spurious false sysrq triggers, it's also desirable to have a way to enable sysrq back. As a measure of balance between on and off options, add MAGIC_SYSRQ_SERIAL_SEQUENCE which is a string sequence that can enable sysrq if it follows BREAK on a serial line. The longer the string - the less likely it may be in the garbage. Having the way to enable sysrq was beneficial to debug lockups with a manual investigation in field and on the other side preventing false sysrq detections. Based-on-patch-by: Vasiliy Khoruzhick <vasilykh@arista.com> Signed-off-by: Dmitry Safonov <dima@arista.com> Link: https://lore.kernel.org/r/20200302175135.269397-3-dima@arista.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-17serial: core: Switch to use DEVICE_ATTR_RO()Andy Shevchenko1-29/+28
Move device attributes to DEVICE_ATTR_RO() as that would make things a lot more "obvious" what is happening here. Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200217114016.49856-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-14serial: core: use octal permissions on module paramAndy Shevchenko1-13/+13
Symbolic permissions 'S_IRUSR | S_IRGRP' are not preferred. Use octal permissions '0440'. This also makes code shorter. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200214114339.53897-4-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-14serial: core: Consolidate spin lock initialization codeAndy Shevchenko1-18/+16
We have two times duplicated excerpt where we initialize spin lock for UART port. Consolidate it under uart_port_spin_lock_init() helper. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200214114339.53897-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-14serial: core: Introduce uart_console_enabled() helperAndy Shevchenko1-2/+7
Introduce uart_console_enabled() helper which checks port to be console and console is registered in the list. Note, this helper will be used in the future as well. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200214114339.53897-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-10serial_core: Move sysrq functions from header fileDmitry Safonov1-0/+83
It's not worth to have them in every serial driver and I'm about to add another helper function. Signed-off-by: Dmitry Safonov <dima@arista.com> Link: https://lore.kernel.org/r/20200109215444.95995-2-dima@arista.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-10tty: serial_core: Export uart_console_device so it can be used by modulesJohn Stultz1-0/+1
In order to support serial console w/ SERIAL_QCOM_GENI=m, we need to export the uart_console_device() symbol so things will build Cc: Todd Kjos <tkjos@google.com> Cc: Alistair Delva <adelva@google.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-serial@vger.kernel.org Signed-off-by: John Stultz <john.stultz@linaro.org> Link: https://lore.kernel.org/r/20200107010311.58584-1-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17tty: link tty and port before configuring it as consoleSudip Mukherjee1-0/+1
There seems to be a race condition in tty drivers and I could see on many boot cycles a NULL pointer dereference as tty_init_dev() tries to do 'tty->port->itty = tty' even though tty->port is NULL. 'tty->port' will be set by the driver and if the driver has not yet done it before we open the tty device we can get to this situation. By adding some extra debug prints, I noticed that: 6.650130: uart_add_one_port 6.663849: register_console 6.664846: tty_open 6.674391: tty_init_dev 6.675456: tty_port_link_device uart_add_one_port() registers the console, as soon as it registers, the userspace tries to use it and that leads to tty_open() but uart_add_one_port() has not yet done tty_port_link_device() and so tty->port is not yet configured when control reaches tty_init_dev(). Further look into the code and tty_port_link_device() is done by uart_add_one_port(). After registering the console uart_add_one_port() will call tty_port_register_device_attr_serdev() and tty_port_link_device() is called from this. Call add tty_port_link_device() before uart_configure_port() is done and add a check in tty_port_link_device() so that it only links the port if it has not been done yet. Suggested-by: Jiri Slaby <jslaby@suse.com> Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191212131602.29504-1-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-09-04 05:09:54 +0300