summaryrefslogtreecommitdiffstats
path: root/drivers/tty
AgeCommit message (Collapse)AuthorFilesLines
2022-05-19serial: jsm: Use B0 instead of 0Ilpo Järvinen2-2/+2
Use B0 to check zero baudrate rather than literal 0. While at it, remove extra parenthesis around CBAUD. Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220513082906.11096-6-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19serial: fsl_lpuart: Remove unnecessary clearing for CRTSCTSIlpo Järvinen1-5/+3
if (termios->c_cflag & CRTSCTS) guarantees that CRTSCTS is not ever set in the else block so clearing it is unnecessary. While at it, remove also one pair of extra parenthesis. Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220513082906.11096-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19tty: remove IBSHIFT ifdefsIlpo Järvinen1-12/+3
IBSHIFT is defined by all architectures since commit d0ffb805b729 ("arch/alpha, termios: implement BOTHER, IBSHIFT and termios2"). Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220513082906.11096-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19tty: remove BOTHER ifdefsIlpo Järvinen3-20/+7
BOTHER is defined by all architectures since commit d0ffb805b729 ("arch/alpha, termios: implement BOTHER, IBSHIFT and termios2"). Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220513082906.11096-3-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19tty: remove CMSPAR ifdefsIlpo Järvinen5-18/+0
CMSPAR is defined by all architectures since commit 6bf08cb246b5 ("[PATCH] Add CMSPAR to termbits.h for powerpc and alpha"). Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220513082906.11096-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19tty: serial: samsung_tty: Fix suspend/resume on S5LHector Martin1-0/+1
We were restoring the IRQ masks then clearing them again, because ucon_mask wasn't set properly. Adding that makes suspend/resume work as intended. Signed-off-by: Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20220502092505.30934-1-marcan@marcan.st Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19serial: pmac_zilog: remove initial printJiri Slaby1-2/+0
Don't report about the driver when loaded. It's unneeded and frowned upon nowadays. Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220519075653.31356-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19serial: pmac_zilog: remove tracing printsJiri Slaby1-25/+1
Remove debug printouts upon function enter/exit. This can be achieved better by tracing. Remove also the one protected by DEBUG_HARD which is not defined anyway. Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220519075653.31356-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19serial: pmac_zilog: remove unused uart_pmac_port::termios_cacheJiri Slaby2-4/+0
struct uart_pmac_port contains termios_cache. It is only written and never read. Remove it as it only occupies space. Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220519075653.31356-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19serial: pmac_zilog: remove unfinished DBDMA supportJiri Slaby2-46/+1
The support for DBDMA was never completed. Remove the the code that only maps spaces without real work. Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220519075653.31356-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19serial: amba-pl011: move header content to .cJiri Slaby2-37/+30
There is no point keeping the header content separated. In this case, it is only an enum. So move the enum to the appropriate source file. Cc: Russell King <linux@armlinux.org.uk> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220519075720.31402-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19tty: n_gsm: Fix packet data hex dump outputTony Lindgren1-8/+23
The module param debug for n_gsm uses KERN_INFO level, but the hexdump now uses KERN_DEBUG level. This started after commit 091cb0994edd ("lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds"). We now use dynamic_hex_dump() unless DEBUG is set. This causes no packets to be seen with modprobe n_gsm debug=0x1f unlike earlier. Let's fix this by adding gsm_hex_dump_bytes() that calls print_hex_dump() with KERN_INFO to match what n_gsm is doing with the other debug related output. Fixes: 091cb0994edd ("lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds") Cc: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20220512131506.1216-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-16Merge 5.18-rc7 into usb-nextGreg Kroah-Hartman4-29/+43
We need the tty fixes in here as well, as we need to revert one of them :( Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12tty: fix deadlock caused by calling printk() under tty_port->lockQi Zheng1-1/+2
pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner); vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023 vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 fail_dump lib/fault-inject.c:45 [inline] should_fail+0x67b/0x7c0 lib/fault-inject.c:144 __should_failslab+0x152/0x1c0 mm/failslab.c:33 should_failslab+0x5/0x10 mm/slab_common.c:1224 slab_pre_alloc_hook mm/slab.h:468 [inline] slab_alloc_node mm/slub.c:2723 [inline] slab_alloc mm/slub.c:2807 [inline] __kmalloc+0x72/0x300 mm/slub.c:3871 kmalloc include/linux/slab.h:582 [inline] tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175 __tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273 tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318 tty_insert_flip_string include/linux/tty_flip.h:37 [inline] pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock); n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356 do_tty_write drivers/tty/tty_io.c:961 [inline] tty_write+0x512/0x930 drivers/tty/tty_io.c:1045 __vfs_write+0x76/0x100 fs/read_write.c:494 [...] other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &port->lock Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com Fixes: b6da31b2c07c ("tty: Fix data race in tty_insert_flip_string_fixed_flag") Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com> Acked-by: Jiri Slaby <jirislaby@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Akinobu Mita <akinobu.mita@gmail.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-05-11signal: Replace __group_send_sig_info with send_signal_lockedEric W. Biederman1-2/+2
The function __group_send_sig_info is just a light wrapper around send_signal_locked with one parameter fixed to a constant value. As the wrapper adds no real value update the code to directly call the wrapped function. Tested-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Link: https://lkml.kernel.org/r/20220505182645.497868-2-ebiederm@xmission.com Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2022-05-05fsl_lpuart: Don't enable interrupts too earlyIndan Zupancic1-9/+9
If an irq is pending when devm_request_irq() is called, the irq handler will cause a NULL pointer access because initialisation is not done yet. Fixes: 9d7ee0e28da59 ("tty: serial: lpuart: avoid report NULL interrupt") Cc: stable <stable@vger.kernel.org> Signed-off-by: Indan Zupancic <Indan.Zupancic@mep-info.com> Link: https://lore.kernel.org/r/20220505114750.45423-1-Indan.Zupancic@mep-info.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05tty: n_gsm: fix invalid gsmtty_write_room() resultDaniel Starke1-4/+3
gsmtty_write() does not prevent the user to use the full fifo size of 4096 bytes as allocated in gsm_dlci_alloc(). However, gsmtty_write_room() tries to limit the return value by 'TX_SIZE' and returns a negative value if the fifo has more than 'TX_SIZE' bytes stored. This is obviously wrong as 'TX_SIZE' is defined as 512. Define 'TX_SIZE' to the fifo size and use it accordingly for allocation to keep the current behavior. Return the correct remaining size of the fifo in gsmtty_write_room() via kfifo_avail(). Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke <daniel.starke@siemens.com> Link: https://lore.kernel.org/r/20220504081733.3494-3-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05tty: n_gsm: fix mux activation issues in gsm_config()Daniel Starke1-4/+8
The current implementation activates the mux if it was restarted and opens the control channel if the mux was previously closed and we are now acting as initiator instead of responder, which is the default setting. This has two issues. 1) No mux is activated if we keep all default values and only switch to initiator. The control channel is not allocated but will be opened next which results in a NULL pointer dereference. 2) Switching the configuration after it was once configured while keeping the initiator value the same will not reopen the control channel if it was closed due to parameter incompatibilities. The mux remains dead. Fix 1) by always activating the mux if it is dead after configuration. Fix 2) by always opening the control channel after mux activation. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke <daniel.starke@siemens.com> Link: https://lore.kernel.org/r/20220504081733.3494-2-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05tty: n_gsm: fix buffer over-read in gsm_dlci_data()Daniel Starke1-0/+1
'len' is decreased after each octet that has its EA bit set to 0, which means that the value is encoded with additional octets. However, the final octet does not decreases 'len' which results in 'len' being one byte too long. A buffer over-read may occur in tty_insert_flip_string() as it tries to read one byte more than the passed content size of 'data'. Decrease 'len' also for the final octet which has the EA bit set to 1 to write the correct number of bytes from the internal receive buffer to the virtual tty. Fixes: 2e124b4a390c ("TTY: switch tty_flip_buffer_push") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke <daniel.starke@siemens.com> Link: https://lore.kernel.org/r/20220504081733.3494-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: 8250_mtk: Fix register address for XON/XOFF characterAngeloGioacchino Del Regno1-2/+5
The XON1/XOFF1 character registers are at offset 0xa0 and 0xa8 respectively, so we cannot use the definition in serial_port.h. Fixes: bdbd0a7f8f03 ("serial: 8250-mtk: modify baudrate setting") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220427132328.228297-4-angelogioacchino.delregno@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: 8250_mtk: Make sure to select the right FEATURE_SELAngeloGioacchino Del Regno1-0/+7
Set the FEATURE_SEL at probe time to make sure that BIT(0) is enabled: this guarantees that when the port is configured as AP UART, the right register layout is interpreted by the UART IP. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220427132328.228297-3-angelogioacchino.delregno@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: 8250_mtk: Fix UART_EFR register addressAngeloGioacchino Del Regno1-7/+8
On MediaTek SoCs, the UART IP is 16550A compatible, but there are some specific quirks: we are declaring a register shift of 2, but this is only valid for the majority of the registers, as there are some that are out of the standard layout. Specifically, this driver is using definitions from serial_reg.h, where we have a UART_EFR register defined as 2: this results in a 0x8 offset, but there we have the FCR register instead. The right offset for the EFR register on MediaTek UART is at 0x98, so, following the decimal definition convention in serial_reg.h and accounting for the register left shift of two, add and use the correct register address for this IP, defined as decimal 38, so that the final calculation results in (0x26 << 2) = 0x98. Fixes: bdbd0a7f8f03 ("serial: 8250-mtk: modify baudrate setting") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220427132328.228297-2-angelogioacchino.delregno@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05tty/serial: digicolor: fix possible null-ptr-deref in digicolor_uart_probe()Yang Yingliang1-3/+2
It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. Fixes: 5930cb3511df ("serial: driver for Conexant Digicolor USART") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Baruch Siach <baruch@tkos.co.il> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220505124621.1592697-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05tty: hvc: dcc: Bind driver to CPU core0 for reads and writesShanker Donthineni2-4/+209
Some external debuggers do not handle reads/writes from/to DCC on secondary cores. Each core has its own DCC device registers, so when a core reads or writes from/to DCC, it only accesses its own DCC device. Since kernel code can run on any core, every time the kernel wants to write to the console, it might write to a different DCC. In SMP mode, external debugger creates multiple windows, and each window shows the DCC output only from that core's DCC. The result is that console output is either lost or scattered across windows. Selecting this debug option will enable code that serializes all console input and output to core 0. The DCC driver will create input and output FIFOs that all cores will use. Reads and writes from/to DCC are handled by a workqueue that runs only core 0. This is a debug feature to be used only in early stage development where debug serial console support would not be present. It disables PM feature like CPU hotplug and is not suitable for production environment. Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> Acked-by: Adam Wallis <awallis@codeaurora.org> Signed-off-by: Timur Tabi <timur@codeaurora.org> Signed-off-by: Elliot Berman <eberman@codeaurora.org> Signed-off-by: Sai Prakash Ranjan <quic_saipraka@quicinc.com> Link: https://lore.kernel.org/r/20220428090858.14489-1-quic_saipraka@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pch: inline pop_tx() into handle_tx()Jiri Slaby1-18/+7
Given pop_tx() is a simple loop, inline it directly into handle_tx(). The code in handle_tx() looks much saner and straightforward now. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503080808.28332-6-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pch: simplify pop_tx() even moreJiri Slaby1-7/+5
1) take uart_tx_stopped into account every loop (the same as other uart drivers) 2) no need for 'count' variable, operate on 'size' directly This allows inlining this into handle_tx() nicely in the next patch. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503080808.28332-5-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pch: remove xmit circ_buf size double checkJiri Slaby1-6/+1
One is in handle_tx() (as "min(xmit->head - xmit->tail, fifo_size))", another one in pop_tx() (as uart_circ_empty(xmit)). So keep only the latter. This makes the code simpler and size variable is not needed now. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503080808.28332-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pch: remove debug print from pop_txJiri Slaby1-5/+1
It makes the code overly complicated for no good reason. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503080808.28332-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pch: decomission pch_uart_hal_write()Jiri Slaby1-33/+13
It's horrid and if we inline it into callers, we can get rid of a lot of sugar around. So: * x_char handling becomes a single iowrite8. * xmit->buf handling is a single loop simply writing characters one by one directly from the buf instead of complex cnt_to_end computations. Until the buf is empty or fifo size is reached. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503080808.28332-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pch: don't overwrite xmit->buf[0] by x_charJiri Slaby1-20/+7
When x_char is to be sent, the TX path overwrites whatever is in the circular buffer at offset 0 with x_char and sends it using pch_uart_hal_write(). I don't understand how this was supposed to work if xmit->buf[0] already contained some character. It must have been lost. Remove this whole pop_tx_x() concept and do the work directly in the callers. (Without printing anything using dev_dbg().) Cc: <stable@vger.kernel.org> Fixes: 3c6a483275f4 (Serial: EG20T: add PCH_UART driver) Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503080808.28332-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pch: move size check from pop_tx one level upJiri Slaby1-6/+8
'count' is zero in the pop_tx()'s comparison against 'size'. So the 'if' tries to find out if 'size' is negative or zero and returns in that case. But it cannot be negative, due to previous (size < 0) check in the caller: handle_tx(). So simply move this check from pop_tx() to handle_tx(). Now it's clear that pop_tx() is called only if fifo_size is non-zero. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503080613.27601-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: restore disabled irqs in pic32_uart_startup()Jiri Slaby1-0/+2
pic32_uart_startup() disables interrupts by local_irq_save(). But the function never enables them. The serial core only holds a mutex, so irqs are not restored. So how could this driver work? This irq handling was already present in the driver's initial commit 157b9394709ed (serial: pic32_uart: Add PIC32 UART driver). So is it a candidate for removal? Anyone has a contact to the author: Andrei Pistirica (I believe the one below -- @microchip.com -- will bounce)? Or to someone else @microchip.com? Cc: Andrei Pistirica <andrei.pistirica@microchip.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-12-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: free up irq names correctlyJiri Slaby1-3/+6
struct pic32_sport contains built-up names for irqs. These are freed only in error path of pic32_uart_startup(). And even there, the freeing happens before free_irq(). So fix this by: * moving frees after free_irq(), and * add frees to pic32_uart_shutdown() -- the opposite of pic32_uart_startup(). Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-11-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: don't zero members of kzalloc-ated structureJiri Slaby1-1/+0
struct pic32_sport (sport) has just been kzallocated. So there is no need to zero its member (sport->port) now. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-10-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: don't assign pic32_sport::cts_gpio twiceJiri Slaby1-1/+0
sport->cts_gpio is first assigned -EINVAL and few lines below using of_get_named_gpio(). Remove the first (useless) assignment. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-9-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: convert to_pic32_sport() to an inlineJiri Slaby1-1/+5
'c' is not in wrapped in parentheses in the to_pic32_sport() macro, so it might be problematic wrt macro expansion. Using an inline is always safer in these cases. Both type-wise and macro-expansion-wise. So switch the macro to an inline. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-8-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: remove pic32_get_port() macroJiri Slaby1-12/+4
It's just &sport->port. First, sport was not in parenthesis, so macro expansion could be an issue. Second, it's so simple, that we can expand the macro and make the code really straightforward. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-7-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: simplify pic32_sport::enable_tx_irq handlingJiri Slaby1-7/+6
Make it a bool, so use true+false. And remove the wrap-around macro -- i.e. access the member directly. It makes the code more obvious. BTW the macro did not have 'sport' in parentheses, so it was potentially problematic wrt expansion. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-6-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: simplify clk handlingJiri Slaby1-23/+5
struct pic32_sport::ref_clk is only set, but not read. That means we can remove it. And when we do so, pic32_enable_clock() and pic32_disable_clock() are simple wrappers around clk_prepare_enable() and clk_disable_unprepare() respectively. So we can remove the former two from the code and replace it by the latter two. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-5-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: remove constants from struct pic32_sportJiri Slaby1-12/+3
All the irqflags_* in struct pic32_sport are set to IRQF_NO_THREAD and never updated. So remove pic32_sport::irqflags_* and use the flag directly. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: move header content to .cJiri Slaby2-117/+103
There is no point keeping the header content separated. So move the content to the appropriate source file. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: pic32: remove unused items from the headerJiri Slaby1-9/+0
struct pic32_console_opt and its support are unused in pic32. So remove all that. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220503063122.20957-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: stm32: Use TC interrupt to deassert GPIO RTS in RS485 modeMarek Vasut2-2/+41
In case the RS485 mode is emulated using GPIO RTS, use the TC interrupt to deassert the GPIO RTS, otherwise the GPIO RTS stays asserted after a transmission ended and the RS485 cannot work. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Erwan Le Ray <erwan.leray@foss.st.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jean Philippe Romain <jean-philippe.romain@foss.st.com> Cc: Valentin Caron <valentin.caron@foss.st.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-serial@vger.kernel.org Link: https://lore.kernel.org/r/20220430162845.244655-2-marex@denx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: stm32: Factor out GPIO RTS toggling into separate functionMarek Vasut1-21/+38
Pull out the GPIO RTS enable and disable handling into separate function. Limit the scope of GPIO RTS toggling only to GPIO emulated RS485 too. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Erwan Le Ray <erwan.leray@foss.st.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jean Philippe Romain <jean-philippe.romain@foss.st.com> Cc: Valentin Caron <valentin.caron@foss.st.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-serial@vger.kernel.org Link: https://lore.kernel.org/r/20220430162845.244655-1-marex@denx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: sifive: Remove duplicate `clkin_rate' settingMaciej W. Rozycki1-8/+6
The `clkin_rate' member of `struct sifive_serial_port' now duplicates `uartclk' from nested `struct uart_port', so use `uartclk' throughout and remove `clkin_rate'. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204291656150.9383@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: sifive: Report actual baud base rather than fixed 115200Maciej W. Rozycki1-1/+1
The base baud value reported is supposed to be the highest baud rate that can be set for a serial port. The SiFive FU740-C000 SOC's on-chip UART supports baud rates of up to 1/16 of the input clock rate, which is the bus clock `tlclk'[1], often at 130MHz in the case of the HiFive Unmatched board. However the sifive UART driver reports a fixed value of 115200 instead: 10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 1, base_baud = 115200) is a SiFive UART v0 10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 2, base_baud = 115200) is a SiFive UART v0 even though we already support setting higher baud rates, e.g.: $ tty /dev/ttySIF1 $ stty speed 230400 The baud base value is computed by the serial core by dividing the UART clock recorded in `struct uart_port' by 16, which is also the minimum value of the clock divider supported, so correct the baud base value reported by setting the UART clock recorded to the input clock rate rather than 115200: 10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 1, base_baud = 8125000) is a SiFive UART v0 10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 2, base_baud = 8125000) is a SiFive UART v0 References: [1] "SiFive FU740-C000 Manual", v1p3, SiFive, Inc., August 13, 2021, Section 16.9 "Baud Rate Divisor Register (div)", pp.143-144 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1f1496a923b6 ("riscv: Fix sifive serial driver") Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204291656280.9383@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: 8250: Add proper clock handling for OxSemi PCIe devicesMaciej W. Rozycki1-68/+271
Oxford Semiconductor PCIe (Tornado) 950 serial port devices are driven by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock. We currently drive the device using its default oversampling rate of 16 and the clock prescaler disabled, consequently yielding the baud base of 3906250. This base is inadequate for some of the high-speed baud rates such as 460800bps, for which the closest rate possible can be obtained by dividing the baud base by 8, yielding the baud rate of 488281.25bps, which is off by 5.9638%. This is enough for data communication to break with the remote end talking actual 460800bps, where missed stop bits have been observed. We can do better however, by taking advantage of a reduced oversampling rate, which can be set to any integer value from 4 to 16 inclusive by programming the TCR register, and by using the clock prescaler, which can be set to any value from 1 to 63.875 in increments of 0.125 in the CPR/CPR2 register pair. The prescaler has to be explicitly enabled though by setting bit 7 in the MCR or otherwise it is bypassed (in the enhanced mode that we enable) as if the value of 1 was used. Make use of these features then as follows: - Set the baud base to 15625000, reflecting the minimum oversampling rate of 4 with the clock prescaler and divisor both set to 1. - Override the `set_mctrl' and set the MCR shadow there so as to have MCR[7] always set and have the 8250 core propagate these settings. - Override the `get_divisor' handler and determine a good combination of parameters by using a lookup table with predetermined value pairs of the oversampling rate and the clock prescaler and finding a pair that divides the input clock such that the quotient, when rounded to the nearest integer, deviates the least from the exact result. Calculate the clock divisor accordingly. Scale the resulting oversampling rate (only by powers of two) if possible so as to maximise it, reducing the divisor accordingly, and avoid a divisor overflow for very low baud rates by scaling the oversampling rate and/or the prescaler even if that causes some accuracy loss. Also handle the historic spd_cust feature so as to allow one to set all the three parameters manually to arbitrary values, by keeping the low 16 bits for the divisor and then putting TCR in bits 19:16 and CPR/CPR2 in bits 28:20, sanitising the bit pattern supplied such as to clamp CPR/CPR2 values between 0.000 and 0.875 inclusive to 33.875. This preserves compatibility with any existing setups, that is where requesting a custom divisor that only has any bits set among the low 16 the oversampling rate of 16 and the clock prescaler of 33.875 will be used as with the original 8250. Finally abuse the `frac' argument to store the determined bit patterns for the TCR, CPR and CPR2 registers. - Override the `set_divisor' handler so as to set the TCR, CPR and CPR2 registers from the `frac' value supplied. Set the divisor as usual. With the baud base set to 15625000 and the unsigned 16-bit UART_DIV_MAX limitation imposed by `serial8250_get_baud_rate' standard baud rates below 300bps become unavailable in the regular way, e.g. the rate of 200bps requires the baud base to be divided by 78125 and that is beyond the unsigned 16-bit range. The historic spd_cust feature can still be used to obtain such rates if so required. See Documentation/tty/device_drivers/oxsemi-tornado.rst for more details. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181519450.9383@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: 8250: Export ICR access helpers for internal useMaciej W. Rozycki2-21/+22
Make ICR access helpers available outside 8250_port.c, however retain them as ordinary static functions so as not to regress code generation. This is because `serial_icr_write' is currently automatically inlined by GCC, however `serial_icr_read' is not. Making them both static inline would grow code produced, e.g.: $ i386-linux-gnu-size --format=gnu 8250_port-{old,new}.o text data bss total filename 15065 3378 0 18443 8250_port-old.o 15289 3378 0 18667 8250_port-new.o and: $ riscv64-linux-gnu-size --format=gnu 8250_port-{old,new}.o text data bss total filename 16980 5306 0 22286 8250_port-old.o 17124 5306 0 22430 8250_port-new.o while making them external would needlessly add a new module interface and lose the benefit from `serial_icr_write' getting inlined outside 8250_port.o. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181517500.9383@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: 8250: Fold EndRun device support into OxSemi Tornado codeMaciej W. Rozycki1-51/+25
The EndRun PTP/1588 dual serial port device is based on the Oxford Semiconductor OXPCIe952 UART device with the PCI vendor:device ID set for EndRun Technologies and uses the same sequence to determine the number of ports available. Despite that we have duplicate code specific to the EndRun device. Remove redundant code then and factor out OxSemi Tornado device detection. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181516220.9383@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-05serial: men_z135_uart: Drop duplicated iotype assignmentIlpo Järvinen1-1/+0
The driver assigns same iotype twice. Drop one of them. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/14b71e1-2396-3d83-3a97-9582765d453@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-17 02:09:32 +0000