- 15 Apr, 2022 29 commits
-
-
Al Cooper authored
When flow control is enabled, the UART should set RTS to false during suspend to stop incoming data. Currently, the suspend routine sets the mctrl register in the uart to zero, but leaves the shadow version in the uart_port struct alone so that resume can restore it. This causes a problem later in suspend when serial8250_do_shutdown() is called which uses the shadow mctrl register to clear some additional bits but ends up restoring RTS. The solution is to clear RTS from the shadow version before serial8250_do_shutdown() is called and restore it after. Signed-off-by:
Al Cooper <alcooperx@comcast.net> Link: https://lore.kernel.org/r/20220324145620.41573-1-alcooperx@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Tremblay authored
Signed-off-by:
Eric Tremblay <etremblay@distech-controls.com> Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220330104642.229507-4-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Eric Tremblay authored
The Freescale variant of the 16550A doesn't have an interrupt on TEMT available when using the FIFO mode. Signed-off-by:
-
Eric Tremblay authored
Introduce the UART_CAP_NOTEMT capability. The capability indicates that the UART doesn't have an interrupt available on TEMT. In the case where the device does not support it, we calculate the maximum time it could take for the transmitter to empty the shift register. When we get in the situation where we get the THRE interrupt, we check if the TEMT bit is set. If it's not, we start the a timer and recall __stop_tx() after the delay. The transmit sequence is a bit modified when the capability is set. The new timer is used between the last interrupt(THRE) and a potential stop_tx timer. Signed-off-by:
Giulio Benetti <giulio.benetti@micronovasrl.com> [moved to use added UART_CAP_TEMT] Signed-off-by:
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> [moved to use added UART_CAP_NOTEMT, improve timeout] Signed-off-by:
-
Miaoqian Lin authored
platform_get_resource() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference. Fixes: 54da3e38 ("serial: 8250_aspeed_vuart: use UPF_IOREMAP to set up register mapping") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220404143842.16960-1-linmq006@gmail.comSigned-off-by:
-
Lino Sanfilippo authored
In uart_set_rs485_config() the serial core already assigns the passed serial_rs485 struct to the uart port. So remove the assignment from the drivers rs485_config() function to avoid redundancy. Reviewed-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by:
Richard Genoud <richard.genoud@gmail.com> Signed-off-by:
Lino Sanfilippo <LinoSanfilippo@gmx.de> Link: https://lore.kernel.org/r/20220410104642.32195-10-LinoSanfilippo@gmx.deSigned-off-by:
-
Lino Sanfilippo authored
In uart_set_rs485_config() the serial core already ensures that only one of both options RTS on send or RTS after send is set. It also assigns the passed serial_rs485 struct to the uart port. So remove the check and the assignment from the drivers rs485_config() function to avoid redundancy. Signed-off-by:
-
Lino Sanfilippo authored
In uart_set_rs485_config() the serial core already assigns the passed serial_rs485 struct to the uart port. So remove the assignment in the drivers rs485_config() function to avoid reduncancy. Acked-by:
-
Lino Sanfilippo authored
In uart_set_rs485_config() the serial core already nullifies the padding field of the passed serial_rs485 struct before returning it to userspace. Doing the same in the drivers rs485_config() function is redundant, so remove the concerning memset in this function. Signed-off-by:
-
Lino Sanfilippo authored
In uart_set_rs485_config() the serial core already clamps the RTS delays. It also assigns the passed serial_rs485 struct to the uart port. So remove these tasks from the drivers rs485_config() function to avoid redundancy. Signed-off-by:
-
Lino Sanfilippo authored
In uart_set_rs485_config() the serial core already ensures that only one of both options RTS on send or RTS after send is set. So remove this check from the drivers rs485_config() function to avoid redundancy. Signed-off-by:
-
Lino Sanfilippo authored
In uart_set_rs485_config() the serial core already ensures that only one of both options RTS on send or RTS after send is set. It also assigns the passed serial_rs485 struct to the uart port. So remove the check and the assignment from the drivers rs485_config() function to avoid redundancy. Signed-off-by:
-
Lino Sanfilippo authored
In uart_set_rs485_config() the serial core already - ensures that only one of both options RTS on send or RTS after send is set - nullifies the padding field of the passed serial_rs485 struct - clamps the RTS delays - assigns the passed serial_rs485 struct to the uart port So remove these tasks from the code of the drivers rs485_config() function to avoid redundancy. Signed-off-by:
-
Lino Sanfilippo authored
Several drivers that support setting the RS485 configuration via userspace implement one or more of the following tasks: - in case of an invalid RTS configuration (both RTS after send and RTS on send set or both unset) fall back to enable RTS on send and disable RTS after send - nullify the padding field of the returned serial_rs485 struct - copy the configuration into the uart port struct - limit RTS delays to 100 ms Move these tasks into the serial core to make them generic and to provide a consistent behaviour among all drivers. Signed-off-by:
-
Yu Tu authored
Due to chip process differences, chip designers recommend using baud rates as close to and larger as possible in order to reduce clock errors. Signed-off-by:
Yu Tu <yu.tu@amlogic.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20220407081355.13602-2-yu.tu@amlogic.comSigned-off-by:
-
Kuldeep Singh authored
Similar to I2C controller, move geni based QUP UART controller binding out from parent schema to an individual binding and let parent refer to child schema later on. UART binding also stand incomplete right now similar to I2C, complete it along this process. Signed-off-by:
Kuldeep Singh <singh.kuldeep87k@gmail.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220404182938.29492-4-singh.kuldeep87k@gmail.comSigned-off-by:
-
Maciej W. Rozycki authored
Provide information in the kernel log as to what configuration option to enable for PCI UART devices that have been blacklisted in the generic PCI 8250 UART driver and which have a dedicated driver available to handle that has been disabled. The rationale is there is no easy way for the user to map a specific PCI vendor:device pair to an individual dedicated driver while the generic driver has this information readily available and it will likely be confusing that the generic driver does not register such a port. This is unlike usual drivers, such as drivers/net/ethernet/3com/3c59x.c which handles all the hardware family members regardless of differences between them, and following an existing example where a serio driver provides suggestions as to the correct configuration options to use: psmouse serio1: synaptics: The touchpad can support a better bus than the too old PS/2 protocol. Make sure MOUSE_PS2_SYNAPTICS_SMBUS and RMI4_SMB are enabled to get a better touchpad experience. A message is then printed like: serial 0000:04:00.3: ignoring port, enable SERIAL_8250_PERICOM to handle when an affected device is encountered and the generic driver rejects it. Signed-off-by:
Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203310054120.44113@angie.orcam.me.ukSigned-off-by:
-
Daniel Gibson authored
TTYs in ICANON mode have a special case that allows "pushing" a line without a regular EOL character (like newline), by using EOF (the EOT character - ASCII 0x4) as a pseudo-EOL. It is silently discarded, so the reader of the PTS will receive the line *without* EOF or any other terminating character. This special case has an edge case: What happens if the readers buffer is the same size as the line (without EOF)? Will they be able to tell if the whole line is received, i.e. if the next read() will return more of the same line or the next line? There are two possibilities, that both have (dis)advantages: 1. The next read() returns 0. FreeBSD (13.0) and OSX (10.11) do this. Advantage: The reader can interpret this as "the line is over". Disadvantage: read() returning 0 means EOF, the reader could also interpret it as "there's no more data" and stop reading or even close the PT. 2. The next read() returns the next line, the EOF is silently discarded. Solaris (or at least OpenIndiana 2021.10) does this, Linux has done do this since commit 40d5e090 ("n_tty: Fix EOF push handling"); this behavior was recently broken by commit 35930307 ("tty: n_tty: do not look ahead for EOL character past the end of the buffer"). Advantage: read() won't return 0 (EOF), reader less likely to be confused (and things like `while(read(..)>0)` don't break) Disadvantage: The reader can't really know if the read() continues the last line (that filled the whole read buffer) or starts a new line. As both options are defensible (and are used by other Unix-likes), it's best to stick to the "old" behavior since "n_tty: Fix EOF push handling" of 2013, i.e. silently discard that EOF. This patch - that I actually got from Linus for testing and only modified slightly - restores that behavior by skipping an EOF character if it's the next character after reading is done. Based on a patch from Linus Torvalds. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215611 Fixes: 35930307 ("tty: n_tty: do not look ahead for EOL character past the end of the buffer") Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Reviewed-and-tested-by:
Daniel Gibson <daniel@gibson.sh> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Phil Edworthy authored
This is needed for the Renesas RZ/V2M (r9a09g011) SoC. Signed-off-by:
Phil Edworthy <phil.edworthy@renesas.com> Reviewed-by:
Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220330154024.112270-6-phil.edworthy@renesas.comSigned-off-by:
-
Phil Edworthy authored
The Renesas RZ/V2M (r9a09g011) SoC uses a uart that is compatible with the EMMA Mobile SoC. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Peng Fan authored
The lpuart on i.MX93 is derived from i.MX7ULP with some industrial enhancements, it uses two compatible strings, so update the compatible string for i.MX93. Acked-by:
Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220323093659.1722463-1-peng.fan@oss.nxp.comSigned-off-by:
-
Kunihiko Hayashi authored
UniPhier UART controller has a reset lines from system controller. Add "resets" property to fix the following warning. uniphier-ld11-global.dtb: serial@54006800: 'resets' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml Reviewed-by:Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1648617338-8600-3-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by:
-
Kunihiko Hayashi authored
'maxItems' is preferred for a single entry, not 'minItems'. Reviewed-by:
-
Miaoqian Lin authored
Fix the missing clk_disable_unprepare() before return from owl_uart_probe() in the error handling case. Fixes: abf42d2f ("tty: serial: owl: add "much needed" clk_prepare_enable()") Signed-off-by:
-
Jaewon Kim authored
The console_write and IRQ handler can run concurrently. Problems may occurs console_write is continuously executed while the IRQ handler is running. Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20220407071619.102249-2-jaewon02.kim@samsung.comSigned-off-by:
-
Huang Guobin authored
When pci_read_config_dword failed, call pci_release_regions() and pci_disable_device() to recycle the resource previously allocated. Reviewed-by:
Huang Guobin <huangguobin4@huawei.com> Link: https://lore.kernel.org/r/20220331091005.3290753-1-huangguobin4@huawei.comSigned-off-by:
-
Christophe Leroy authored
powerpc's asm/prom.h brings some headers that it doesn't need itself. In order to clean it up, first add missing headers in users of asm/prom.h Reviewed-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/49fc0d4b6446da630b1e9f29c4bab38f8ed087bf.1648833419.git.christophe.leroy@csgroup.euSigned-off-by:
-
Christophe Leroy authored
powerpc's asm/prom.h brings some headers that it doesn't need itself. In order to clean it up, first add missing headers in users of asm/prom.h Signed-off-by:
-
Wang Weiyang authored
In goldfish_tty_probe(), the port initialized through tty_port_init() should be destroyed in error paths.In goldfish_tty_remove(), qtty->port also should be destroyed or else might leak resources. Fix the above by calling tty_port_destroy(). Fixes: 666b7793 ("goldfish: tty driver") Reviewed-by:
Wang Weiyang <wangweiyang2@huawei.com> Link: https://lore.kernel.org/r/20220328115844.86032-1-wangweiyang2@huawei.comSigned-off-by:
-
- 14 Apr, 2022 10 commits
-
-
Jiri Slaby authored
altera_jtaguart_tx_chars() duplicates what altera_jtaguart_stop_tx() already does. So instead of the duplication, call the helper instead. Not only it makes the code cleaner, but it also says what the "if" really does. Cc: Tobias Klauser <tklauser@distanz.ch> Acked-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220411104506.8990-4-jslaby@suse.czSigned-off-by:
-
Jiri Slaby authored
Flow control characters should be sent even if the TX is stopped. So fix owl-uart to behave the same as other drivers. This unification also allows the use of the TX helper in the future. Cc: "Andreas Färber" <afaerber@suse.de> Cc: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by:
-
Jiri Slaby authored
The code now contains: #ifdef CONFIG_PPC_MPC512x ... #endif #ifdef CONFIG_PPC_MPC512x ... #endif So remove the endif+ifdef from the middle, provided it's about the same define. Signed-off-by:
-
Zheyu Ma authored
When the driver fails at alloc_hdlcdev(), and then we remove the driver module, we will get the following splat: [ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI [ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17] [ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0 [ 25.077709] Call Trace: [ 25.077924] <TASK> [ 25.078108] unregister_hdlc_device+0x16/0x30 [ 25.078481] slgt_cleanup+0x157/0x9f0 [synclink_gt] Fix this by checking whether the 'info->netdev' is a null pointer first. Reviewed-by:
Zheyu Ma <zheyuma97@gmail.com> Link: https://lore.kernel.org/r/20220410114814.3920474-1-zheyuma97@gmail.comSigned-off-by:
-
Jiri Slaby authored
Reformat the whole document, so that automatic numbering and TOC is properly generated. Signed-off-by:
-
Jiri Slaby authored
All of the URLs give 404. There is a little point to preserve them. If really need be, we could try archive.org if the documents are not there by a chance. Signed-off-by:
-
Jiri Slaby authored
It is a tty_driver, not serial -- uart_driver. So move it to the tty docs dir too. (The same as the driver itself.) Signed-off-by:
-
Jiri Slaby authored
We have n_tty documented in Documentation/driver-api/tty/. n_gsm belongs there too, so move from serial/ to tty/ too. Signed-off-by:
-
Jiri Slaby authored
So far only n_tty belongs here, but in the next patches, more will come. Signed-off-by:
-
Jiri Slaby authored
Based on discussion starting as 87mthw2o93.fsf@meer.lwn.net, let's move the tty documentation to driver-api. It's more appropriate there. Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
- 11 Apr, 2022 1 commit
-
-
Linus Torvalds authored
-
