summaryrefslogtreecommitdiffstats
path: root/drivers/tty/serial/8250/8250_omap.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* serial: 8250: omap: Move pm_runtime_get_syncBin Liu2024-11-051-2/+2
| | | | | | | | | | | | | | | | | | | | | Currently in omap_8250_shutdown, the dma->rx_running flag is set to zero in omap_8250_rx_dma_flush. Next pm_runtime_get_sync is called, which is a runtime resume call stack which can re-set the flag. When the call omap_8250_shutdown returns, the flag is expected to be UN-SET, but this is not the case. This is causing issues the next time UART is re-opened and omap_8250_rx_dma is called. Fix by moving pm_runtime_get_sync before the omap_8250_rx_dma_flush. cc: stable@vger.kernel.org Fixes: 0e31c8d173ab ("tty: serial: 8250_omap: add custom DMA-RX callback") Signed-off-by: Bin Liu <b-liu@ti.com> [Judith: Add commit message] Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20241031172315.453750-1-jm@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: Fix typos in comments across various filesYu Jiaoliang2024-10-111-2/+2
| | | | | | | | | | | | | This patch fixes several typos in the comments within the tty/8250 directory to improve readability and code documentation. Detected using codespell. Signed-off-by: Yu Jiaoliang <yujiaoliang@vivo.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240929100931.530620-1-yujiaoliang@vivo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: Switch back to struct platform_driver::remove()Uwe Kleine-König2024-10-111-1/+1
| | | | | | | | | | | | | | | After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/tty/serial to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20241007205803.444994-7-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 6.11-rc4 into tty-nextGreg Kroah-Hartman2024-08-191-28/+5
|\ | | | | | | | | | | We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Revert "serial: 8250_omap: Set the console genpd always on if no console ↵Griffin Kroah-Hartman2024-08-151-28/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | suspend" This reverts commit 68e6939ea9ec3d6579eadeab16060339cdeaf940. Kevin reported that this causes a crash during suspend on platforms that dont use PM domains. Link: https://lore.kernel.org/r/7ha5hgpchq.fsf@baylibre.com Cc: Thomas Richard <thomas.richard@bootlin.com> Fixes: 68e6939ea9ec ("serial: 8250_omap: Set the console genpd always on if no console suspend") Cc: stable <stable@kernel.org> Reported-by: Kevin Hilman <khilman@kernel.org> Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com> Link: https://lore.kernel.org/r/20240814111747.82371-1-griffin@kroah.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250: omap: Parse DT wakeup-source proertyMarkus Schneider-Pargmann2024-08-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | If the wakeup-source property is present, enable wakeup from this device. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20240807141227.1093006-6-msp@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250: omap: Set wakeup capable, do not enableMarkus Schneider-Pargmann2024-08-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The driver sets wakeup enable by default. But not all UARTs are meant to be wakeup enabled. Change the default to be wakeup capable but not enabled. The user can enable wakeup when needed. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Acked-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20240807141227.1093006-5-msp@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250: omap: Cleanup on error in request_irqMarkus Schneider-Pargmann2024-08-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | If devm_request_irq fails, the code does not cleanup many things that were setup before. Instead of directly returning ret we should jump to err. Fixes: fef4f600319e ("serial: 8250: omap: Fix life cycle issues for interrupt handlers") Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20240807141227.1093006-4-msp@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250: omap: Remove unused wakeups_enabledMarkus Schneider-Pargmann2024-08-141-1/+0
|/ | | | | | | | | | This field seems to be unused for quite some time already. Remove it. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20240807141227.1093006-3-msp@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_omap: Fix Errata i2310 with RX FIFO level checkUdit Kumar2024-07-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | Errata i2310[0] says, Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts. Commit 9d141c1e6157 ("serial: 8250_omap: Implementation of Errata i2310") which added the workaround but missed ensuring RX FIFO is really empty before applying the errata workaround as recommended in the errata text. Fix this by adding back check for UART_OMAP_RX_LVL to be 0 for workaround to take effect. [0] https://www.ti.com/lit/pdf/sprz536 page 23 Fixes: 9d141c1e6157 ("serial: 8250_omap: Implementation of Errata i2310") Cc: stable@vger.kernel.org Reported-by: Vignesh Raghavendra <vigneshr@ti.com> Closes: https://lore.kernel.org/all/e96d0c55-0b12-4cbf-9d23-48963543de49@ti.com/ Signed-off-by: Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20240625160725.2102194-1-u-kumar1@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_omap: Implementation of Errata i2310Udit Kumar2024-06-241-5/+20
| | | | | | | | | | | | | | As per Errata i2310[0], Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts, therefore apply Errata i2310 solution. [0] https://www.ti.com/lit/pdf/sprz536 page 23 Fixes: b67e830d38fa ("serial: 8250: 8250_omap: Fix possible interrupt storm on K3 SoCs") Cc: stable@vger.kernel.org Signed-off-by: Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20240619105903.165434-1-u-kumar1@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_omap: Remove unused of_gpio.hAndy Shevchenko2024-04-091-1/+0
| | | | | | | | | of_gpio.h is deprecated and subject to remove. The driver doesn't use it, simply remove the unused header. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240307114048.3642642-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tty: serial: switch from circ_buf to kfifoJiri Slaby (SUSE)2024-04-091-16/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Switch from struct circ_buf to proper kfifo. kfifo provides much better API, esp. when wrap-around of the buffer needs to be taken into account. Look at pl011_dma_tx_refill() or cpm_uart_tx_pump() changes for example. Kfifo API can also fill in scatter-gather DMA structures, so it easier for that use case too. Look at lpuart_dma_tx() for example. Note that not all drivers can be converted to that (like atmel_serial), they handle DMA specially. Note that usb-serial uses kfifo for TX for ages. omap needed a bit more care as it needs to put a char into FIFO to start the DMA transfer when OMAP_DMA_TX_KICK is set. In that case, we have to do kfifo_dma_out_prepare twice: once to find out the tx_size (to find out if it is worths to do DMA at all -- size >= 4), the second time for the actual transfer. All traces of circ_buf are removed from serial_core.h (and its struct uart_state). Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: Al Cooper <alcooperx@gmail.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Kumaravel Thiagarajan <kumaravel.thiagarajan@microchip.com> Cc: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Vineet Gupta <vgupta@kernel.org> Cc: Richard Genoud <richard.genoud@gmail.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev> Cc: Alexander Shiyan <shc_work@mail.ru> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Maciej W. Rozycki <macro@orcam.me.uk> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Taichi Sugaya <sugaya.taichi@socionext.com> Cc: Takao Orito <orito.takao@socionext.com> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konrad.dybcio@linaro.org> Cc: Pali Rohár <pali@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: Laxman Dewangan <ldewangan@nvidia.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: David S. Miller <davem@davemloft.net> Cc: Hammer Hsieh <hammerh0314@gmail.com> Cc: Peter Korsgaard <jacmet@sunsite.dk> Cc: Timur Tabi <timur@kernel.org> Cc: Michal Simek <michal.simek@amd.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20240405060826.2521-13-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tty: 8250_omap: use dmaengine_prep_slave_sg()Jiri Slaby (SUSE)2024-04-091-3/+6
| | | | | | | | | | | | This is a preparatory for the serial-to-kfifo switch. kfifo understands only scatter-gatter approach, so switch to that. No functional change intended, it's just dmaengine_prep_slave_single() inline expanded. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20240405060826.2521-11-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_omap: Switch to use uart_read_port_properties()Andy Shevchenko2024-03-051-19/+10
| | | | | | | | | Since we have now a common helper to read port properties use it instead of sparse home grown solution. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240304123035.758700-12-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 6.7-rc5 into tty-nextGreg Kroah-Hartman2023-12-111-6/+8
|\ | | | | | | | | | | We need the serial fixes in here as well to build off of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250: 8250_omap: Clear UART_HAS_RHR_IT_DIS bitRonald Wahl2023-11-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes commit 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable") which unfortunately set the UART_HAS_RHR_IT_DIS bit in the UART_OMAP_IER2 register and never cleared it. Cc: stable@vger.kernel.org Fixes: 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable") Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20231031110909.11695-1-rwahl@gmx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250: 8250_omap: Do not start RX DMA on THRI interruptRonald Wahl2023-11-231-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting RX DMA on THRI interrupt is too early because TX may not have finished yet. This change is inspired by commit 90b8596ac460 ("serial: 8250: Prevent starting up DMA Rx on THRI interrupt") and fixes DMA issues I had with an AM62 SoC that is using the 8250 OMAP variant. Cc: stable@vger.kernel.org Fixes: c26389f998a8 ("serial: 8250: 8250_omap: Add DMA support for UARTs on K3 SoCs") Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20231101171431.16495-1-rwahl@gmx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250: Convert to platform remove callback returning voidUwe Kleine-König2023-11-231-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> # 8250_bcm* Link: https://lore.kernel.org/r/20231110152927.70601-4-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250: omap: Don't skip resource freeing if ↵Uwe Kleine-König2023-11-231-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | pm_runtime_resume_and_get() failed Returning an error code from .remove() makes the driver core emit the little helpful error message: remove callback returned a non-zero value. This will be ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case. Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a use-after-free. So replace the error return (and with it the little helpful error message) by a more useful error message and continue to cleanup. Fixes: e3f0c638f428 ("serial: 8250: omap: Fix unpaired pm_runtime_put_sync() in omap8250_remove()") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20231110152927.70601-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_omap: Set the console genpd always on if no console suspendThomas Richard2023-10-211-5/+28
| | | | | | | | | | | If the console suspend is disabled, the genpd of the console shall not be powered-off during suspend. Set the flag GENPD_FLAG_ALWAYS_ON to the corresponding genpd during suspend, and restore the original value during the resume. Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> Link: https://lore.kernel.org/r/20231017130540.1149721-1-thomas.richard@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 6.6-rc6 into tty-nextGreg Kroah-Hartman2023-10-161-15/+10
|\ | | | | | | | | | | | | | | | | | | We need the tty/serial fixes in here as well for testing, and this resolves merge conflicts in: drivers/tty/serial/serial_core.c as reported in linux-next Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250_omap: Fix errors with no_console_suspendTony Lindgren2023-10-031-15/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now get errors on system suspend if no_console_suspend is set as reported by Thomas. The errors started with commit 20a41a62618d ("serial: 8250_omap: Use force_suspend and resume for system suspend"). Let's fix the issue by checking for console_suspend_enabled in the system suspend and resume path. Note that with this fix the checks for console_suspend_enabled in omap8250_runtime_suspend() become useless. We now keep runtime PM usage count for an attached kernel console starting with commit bedb404e91bb ("serial: 8250_port: Don't use power management for kernel console"). Fixes: 20a41a62618d ("serial: 8250_omap: Use force_suspend and resume for system suspend") Cc: stable <stable@kernel.org> Cc: Udit Kumar <u-kumar1@ti.com> Reported-by: Thomas Richard <thomas.richard@bootlin.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Thomas Richard <thomas.richard@bootlin.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230926061319.15140-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250_omap: Drop pm_runtime_irq_safe()Tony Lindgren2023-10-051-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's drop the use of pm_runtime_irq_safe() for 8250_omap. The use of pm_runtime_irq_safe() is not nice as it takes a permanent usage count on the parent device. We can finally drop pm_runtime_irq_safe() safely as the kernel now knows when the uart port tx is active. This changed with commit 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM"). For serial port rx, we already use Linux generic wakeirqs for 8250_omap. To drop pm_runtime_irq_safe(), we need to add handling for shallow idle state where the port hardware may already be awake and an IO interrupt happens. We also need to replace the serial8250_rpm sync calls in the interrupt handlers with async runtime PM calls. Note that omap8250_irq() calls omap_8250_dma_handle_irq(), so we don't need separate runtime PM calls in omap_8250_dma_handle_irq(). While at it, let's also add the missing line break to the end of omap8250_runtime_resume() to group the calls. Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20231004062650.64487-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250_omap: Use port lock wrappersThomas Gleixner2023-09-181-26/+26
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a serial port is used for kernel console output, then all modifications to the UART registers which are done from other contexts, e.g. getty, termios, are interference points for the kernel console. So far this has been ignored and the printk output is based on the principle of hope. The rework of the console infrastructure which aims to support threaded and atomic consoles, requires to mark sections which modify the UART registers as unsafe. This allows the atomic write function to make informed decisions and eventually to restore operational state. It also allows to prevent the regular UART code from modifying UART registers while printk output is in progress. All modifications of UART registers are guarded by the UART port lock, which provides an obvious synchronization point with the console infrastructure. To avoid adding this functionality to all UART drivers, wrap the spin_[un]lock*() invocations for uart_port::lock into helper functions which just contain the spin_[un]lock*() invocations for now. In a subsequent step these helpers will gain the console synchronization mechanisms. Converted with coccinelle. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/r/20230914183831.587273-13-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tty: Explicitly include correct DT includesRob Herring2023-07-251-1/+0
| | | | | | | | | | | | | | | | The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> # for imx Link: https://lore.kernel.org/r/20230724205440.767071-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_omap: Use force_suspend and resume for system suspendTony Lindgren2023-06-151-5/+15
| | | | | | | | | | | | | | | | | | | We should not rely on autosuspend timeout for system suspend. Instead, let's use force_suspend and force_resume functions. Otherwise the serial port controller device may not be idled on suspend. As we are doing a register write on suspend to configure the serial port, we still need to runtime PM resume the port on suspend. While at it, let's switch to pm_runtime_resume_and_get() and check for errors returned. And let's add the missing line break before return to the suspend function while at it. Fixes: 09d8b2bdbc5c ("serial: 8250: omap: Provide ability to enable/disable UART as wakeup source") Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Dhruva Gole <d-gole@ti.com> Message-ID: <20230614045922.4798-1-tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: omap: convert to modern PM opsArnd Bergmann2023-05-311-12/+5
| | | | | | | | | | | | | | | | The new uart_write() function is only called from suspend/resume code, causing a build warning when those are left out: drivers/tty/serial/8250/8250_omap.c:169:13: error: 'uart_write' defined but not used [-Werror=unused-function] Remove the #ifdefs and use the modern pm_ops/pm_sleep_ops and their wrappers to let the compiler see where it's used but still drop the dead code. Fixes: 398cecc24846 ("serial: 8250: omap: Fix imprecise external abort for omap_8250_pm()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230517202012.634386-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: omap: Move uart_write() inside PM sectionGeert Uytterhoeven2023-05-311-5/+5
| | | | | | | | | | | | | | | | | | | If CONFIG_PM is not set (e.g. m68k/allmodconfig): drivers/tty/serial/8250/8250_omap.c:169:13: error: ‘uart_write’ defined but not used [-Werror=unused-function] 169 | static void uart_write(struct omap8250_priv *priv, u32 reg, u32 val) | ^~~~~~~~~~ Fix tis by moving uart_write() inside the existing section protected by #ifdef CONFIG_PM. Reported-by: noreply@ellerman.id.au Link: http://kisskb.ellerman.id.au/kisskb/buildresult/14925095/ Fixes: 398cecc24846e867 ("serial: 8250: omap: Fix imprecise external abort for omap_8250_pm()") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230515065706.1723477-1-geert@linux-m68k.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: synchronize and annotate UART_IER accessJohn Ogness2023-05-301-0/+14
| | | | | | | | | | | | | | | | | | The UART_IER register is modified twice by each console write (serial8250_console_write()) under the port lock. Any driver code that accesses UART_IER must do so with the port locked in order to ensure consistent values, even when for read accesses. Add locking, lockdep notation, and/or comments everywhere UART_IER is accessed. The added locking is not fixing a real problem because it occurs where the console is not active. However, adding the locking to these non-critical paths greatly simplifies UART_IER access tracking by establishing a general policy that all UART_IER access is performed with the port locked. Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/r/20230525093159.223817-9-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: lock port for UART_IER access in omap8250_irq()John Ogness2023-05-301-2/+3
| | | | | | | | | | | | | | | | | | omap8250_irq() accesses UART_IER. This register is modified twice by each console write (serial8250_console_write()) under the port lock. omap8250_irq() must also take the port lock to guanentee synchronized access to UART_IER. Since the port lock is already being taken for the stop_rx() callback and since it is safe to call cancel_delayed_work() while holding the port lock, simply extend the port lock region to include UART_IER access. Fixes: 1fe0e1fa3209 ("serial: 8250_omap: Handle optional overrun-throttle-ms property") Signed-off-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230525093159.223817-8-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: lock port for omap8250_restore_regs()John Ogness2023-05-301-1/+7
| | | | | | | | | | | | | | | | | | | | | | | omap8250_restore_regs() accesses UART_IER. This register is modified twice by each console write (serial8250_console_write()) under the port lock. However, not all calls to omap8250_restore_regs() are under the port lock. Add the missing port locking around omap8250_restore_regs() calls. Add lockdep notation to the omap8250_restore_regs(). Note that this is not fixing a real problem because the serial devices are resumed before console printing is enabled. However, adding this locking allows for clean locking semantics for omap8250_restore_regs() so that lockdep can be used to identify possible problems in the future. It also simplifies synchronization of UART_IER in general by not needing to rely on such implementation details. Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/r/20230525093159.223817-7-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: lock port for rx_dma() callbackJohn Ogness2023-05-301-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | The rx_dma() callback (omap_8250_rx_dma) accesses UART_IER. This register is modified twice by each console write (serial8250_console_write()) under the port lock. However, not all calls to the rx_dma() callback are under the port lock. Add the missing port locking around rx_dma() callback calls. Add lockdep notation to the omap_8250_rx_dma(). Note that this is not fixing a real problem because: 1. Currently DMA is forced off for 8250_omap consoles. 2. The serial devices are resumed before console printing is enabled. However, adding this locking allows for clean locking semantics for the rx_dma() callback so that lockdep can be used to identify possible problems in the future. It also simplifies synchronization of UART_IER in general by not needing to rely on implementation details such as 1 and 2. Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/r/20230525093159.223817-6-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: lock port for stop_rx() in omap8250_irq()John Ogness2023-05-301-0/+2
| | | | | | | | | | | The uarts_ops stop_rx() callback expects that the port->lock is taken and interrupts are disabled. Fixes: 1fe0e1fa3209 ("serial: 8250_omap: Handle optional overrun-throttle-ms property") Signed-off-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230525093159.223817-4-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: lock port in startup() callbacksJohn Ogness2023-05-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | uart_ops startup() callback is called without interrupts disabled and without port->lock locked, relatively late during the boot process (from the call path of console_on_rootfs()). If the device is a console, it was already previously registered and could be actively printing messages. The console printing function serial8250_console_write() modifies the interrupt register (UART_IER) under the port->lock with the pattern: read, clear, restore. Since some startup() callbacks are modifying UART_IER without the port->lock locked, it is possible that the value intended to be written by the startup() callback will get overwritten and be lost. CPU0 CPU1 serial8250_console_write omap_8250_startup -------------------------- ----------------- spin_lock(port->lock) oldval = read(UART_IER) uart_console_write() write(newval, UART_IER) write(oldval, UART_IER) spin_unlock(port->lock) Add port->lock synchronization to the 8250 startup() callbacks where they need to access UART_IER. This avoids racing with serial8250_console_write(). Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/r/20230525093159.223817-2-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: omap: Shut down on remove for console uartTony Lindgren2023-05-131-16/+20
| | | | | | | | | | | | | | | | | | | | | When unbinding the console uart, we want to power down the uart hardware on remove. For the console uart, the normal shutdown path will never get called as the cons_filp stays open. Let's rearrange the dma related functions a bit so we can call driver shutdown also on console uart rebind. Currently we set up->dma on probe, but that causes issues calling omap_8250_shutdown() on remove. The dma startup will not get called on the next rebind as we still have up->dma set from probe. Note that serial8250_release_dma() already checks for dma so we can remove the check for it in 8205_omap driver. With these changes we also avoid hogging dma virtual channels for the unused uarts that may be limited on some devices. Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230508082014.23083-5-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: omap: Fix life cycle issues for interrupt handlersTony Lindgren2023-05-131-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | We have the struct uart_8250_port instance recycled on device rebind while the struct omap8250_priv instance is not. For the console uart, __tty_hangup() does not call tty->ops->hangup() as cons_filp stays open, and uart shutdown won't get called. This means we have a stale priv->wakeirq handler around after unbind, and port->irq is not freed on unbind. There's no need to claim the interrupts on startup. We can fix this and simplify the driver a bit by claiming the interrupts in probe, and clearing them on remove. For the device interrupt, we can use devm_request_irq(). To do this, we change omap8250_irq() to use struct omap8250_priv data directly so we don't have to wait for the assigned port from serial8250_register_8250_port(). We must also drop IRQF_SHARED to set IRQ_NOAUTOEN to avoid spurious interrupts until the port has been registered. There's no need for IRQF_SHARED for 8250_omap, the serial port interrupt lines are dedicated lines. Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230508082014.23083-4-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: omap: Fix imprecise external abort for omap_8250_pm()Tony Lindgren2023-05-131-32/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We must idle the uart only after serial8250_unregister_port(). Otherwise unbinding the uart via sysfs while doing cat on the port produces an imprecise external abort: mem_serial_in from omap_8250_pm+0x44/0xf4 omap_8250_pm from uart_hangup+0xe0/0x194 uart_hangup from __tty_hangup.part.0+0x37c/0x3a8 __tty_hangup.part.0 from uart_remove_one_port+0x9c/0x22c uart_remove_one_port from serial8250_unregister_port+0x60/0xe8 serial8250_unregister_port from omap8250_remove+0x6c/0xd0 omap8250_remove from platform_remove+0x28/0x54 Turns out the driver needs to have runtime PM functional before the driver probe calls serial8250_register_8250_port(). And it needs runtime PM after driver remove calls serial8250_unregister_port(). On probe, we need to read registers before registering the port in omap_serial_fill_features_erratas(). We do that with custom uart_read() already. On remove, after serial8250_unregister_port(), we need to write to the uart registers to idle the device. Let's add a custom uart_write() for that. Currently the uart register access depends on port->membase to be initialized, which won't work after serial8250_unregister_port(). Let's use priv->membase instead, and use it for runtime PM related functions to remove the dependency to port->membase for early and late register access. Note that during use, we need to check for a valid port in the runtime PM related functions. This is needed for the optional wakeup configuration. We now need to set the drvdata a bit earlier so it's available for the runtime PM functions. With the port checks in runtime PM functions, the old checks for priv in omap8250_runtime_suspend() and omap8250_runtime_resume() functions are no longer needed and are removed. Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230508082014.23083-3-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: omap: Fix freeing of resources on failed registerTony Lindgren2023-05-131-0/+2
| | | | | | | | | | | If serial8250_register_8250_port() fails, the SoC can hang as the deferred PMQoS work will still run as is not flushed and removed. Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230508082014.23083-2-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 6.1-rc6 into tty-nextGreg Kroah-Hartman2022-11-221-22/+30
|\ | | | | | | | | | | We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250: omap: Flush PM QOS work on removeTony Lindgren2022-11-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Rebinding 8250_omap in a loop will at some point produce a warning for kernel/power/qos.c:296 cpu_latency_qos_update_request() with error "cpu_latency_qos_update_request called for unknown object". Let's flush the possibly pending PM QOS work scheduled from omap8250_runtime_suspend() before we disable runtime PM. Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20221028110044.54719-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250: omap: Fix unpaired pm_runtime_put_sync() in omap8250_remove()Tony Lindgren2022-11-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On remove, we get an error for "Runtime PM usage count underflow!". I guess this driver is mostly built-in, and this issue has gone unnoticed for a while. Somehow I did not catch this issue with my earlier fix done with commit 4e0f5cc65098 ("serial: 8250_omap: Fix probe and remove for PM runtime"). Fixes: 4e0f5cc65098 ("serial: 8250_omap: Fix probe and remove for PM runtime") Signed-off-by: Tony Lindgren <tony@atomide.com> Depends-on: dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") Link: https://lore.kernel.org/r/20221028105813.54290-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250_omap: remove wait loop from Errata i202 workaroundMatthias Schiffer2022-11-031-17/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were occasionally seeing the "Errata i202: timedout" on an AM335x board when repeatedly opening and closing a UART connected to an active sender. As new input may arrive at any time, it is possible to miss the "RX FIFO empty" condition, forcing the loop to wait until it times out. Nothing in the i202 Advisory states that such a wait is even necessary; other FIFO clear functions like serial8250_clear_fifos() do not wait either. For this reason, it seems safe to remove the wait, fixing the mentioned issue. Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/20221013112339.2540767-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250: omap: Fix missing PM runtime calls for omap8250_set_mctrl()Tony Lindgren2022-11-031-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are cases where omap8250_set_mctrl() may get called after the UART has already autoidled causing an asynchronous external abort. This can happen on ttyport_open(): mem_serial_in from omap8250_set_mctrl+0x38/0xa0 omap8250_set_mctrl from uart_update_mctrl+0x4c/0x58 uart_update_mctrl from uart_dtr_rts+0x60/0xa8 uart_dtr_rts from tty_port_block_til_ready+0xd0/0x2a8 tty_port_block_til_ready from uart_open+0x14/0x1c uart_open from ttyport_open+0x64/0x148 And on ttyport_close(): omap8250_set_mctrl from uart_update_mctrl+0x3c/0x48 uart_update_mctrl from uart_dtr_rts+0x54/0x9c uart_dtr_rts from tty_port_shutdown+0x78/0x9c tty_port_shutdown from tty_port_close+0x3c/0x74 tty_port_close from ttyport_close+0x40/0x58 It can also happen on disassociate_ctty() calling uart_shutdown() that ends up calling omap8250_set_mctrl(). Let's fix the issue by adding missing PM runtime calls to omap8250_set_mctrl(). To do this, we need to add __omap8250_set_mctrl() that can be called from both omap8250_set_mctrl(), and from runtime PM resume path when restoring the registers. Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Reported-by: Merlijn Wajer <merlijn@wizzup.org> Reported-by: Romain Naour <romain.naour@smile.fr> Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Depends-on: dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") Link: https://lore.kernel.org/r/20221024063613.25943-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250: 8250_omap: Avoid RS485 RTS glitch on ->set_termios()Lukas Wunner2022-11-031-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RS485-enabled UART ports on TI Sitara SoCs with active-low polarity exhibit a Transmit Enable glitch on ->set_termios(): omap8250_restore_regs(), which is called from omap_8250_set_termios(), sets the TCRTLR bit in the MCR register and clears all other bits, including RTS. If RTS uses active-low polarity, it is now asserted for no reason. The TCRTLR bit is subsequently cleared by writing up->mcr to the MCR register. That variable is always zero, so the RTS bit is still cleared (incorrectly so if RTS is active-high). (up->mcr is not, as one might think, a cache of the MCR register's current value. Rather, it only caches a single bit of that register, the AFE bit. And it only does so if the UART supports the AFE bit, which OMAP does not. For details see serial8250_do_set_termios() and serial8250_do_set_mctrl().) Finally at the end of omap8250_restore_regs(), the MCR register is restored (and RTS deasserted) by a call to up->port.ops->set_mctrl() (which equals serial8250_set_mctrl()) and serial8250_em485_stop_tx(). So there's an RTS glitch between setting TCRTLR and calling serial8250_em485_stop_tx(). Avoid by using a read-modify-write when setting TCRTLR. While at it, drop a redundant initialization of up->mcr. As explained above, the variable isn't used by the driver and it is already initialized to zero because it is part of the static struct serial8250_ports[] declared in 8250_core.c. (Static structs are initialized to zero per section 6.7.8 nr. 10 of the C99 standard.) Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Su Bao Cheng <baocheng.su@siemens.com> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/6554b0241a2c7fd50f32576fdbafed96709e11e8.1664278942.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250: 8250_omap: Fix calculation of RS485 delaysLukas Wunner2022-11-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 801954d1210a ("serial: 8250: 8250_omap: Support native RS485") calculates RS485 delays from the baudrate. The baudrate is generated with either a 16x or 13x divisor. The divisor is set in the Mode Definition Register 1 (MDR1). The commit erroneously assumes that the register stores the divisor as a bitmask and uses a logical AND to differentiate between 16x and 13x divisors. However the divisor is really stored as a 3-bit mode (see lines 363ff in include/uapi/linux/serial_reg.h). The logical AND operation is performed with UART_OMAP_MDR1_16X_MODE, which is defined as 0x0 and hence yields false. So the commit always assumes a 13x divisor. Fix by using an equal comparison. This works because we never set any of the other 5 bits in the register. (They pertain to IrDA mode, which is not supported by the driver). Fixes: 801954d1210a ("serial: 8250: 8250_omap: Support native RS485") Link: https://lore.kernel.org/linux-serial/202211070440.8hWunFUN-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/7d5b04da13d89b8708b9543a0b125f2b6062a77b.1667977259.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250: 8250_omap: Support native RS485Lukas Wunner2022-11-031-3/+82
|/ | | | | | | | | | | | | | | | | | | | | Recent TI Sitara SoCs such as AM64/AM65 have gained the ability to automatically assert RTS when data is transmitted, obviating the need to emulate this functionality in software. The feature is controlled through new DIR_EN and DIR_POL bits in the Mode Definition Register 3. For details see page 8783 and 8890 of the AM65 TRM: https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Cc: Su Bao Cheng <baocheng.su@siemens.com> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Bin Liu <b-liu@ti.com> Tested-by: Zeng Chao <chao.zeng@siemens.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/e9f25f5c9200a35d3162973c2b45d6b892cc9bf2.1665906869.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: Deassert Transmit Enable on probe in driver-specific wayLukas Wunner2022-09-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a UART port is newly registered, uart_configure_port() seeks to deassert RS485 Transmit Enable by setting the RTS bit in port->mctrl. However a number of UART drivers interpret a set RTS bit as *assertion* instead of deassertion: Affected drivers include those using serial8250_em485_config() (except 8250_bcm2835aux.c) and some using mctrl_gpio (e.g. imx.c). Since the interpretation of the RTS bit is driver-specific, it is not suitable as a means to centrally deassert Transmit Enable in the serial core. Instead, the serial core must call on drivers to deassert it in their driver-specific way. One way to achieve that is to call ->rs485_config(). It implicitly deasserts Transmit Enable. So amend uart_configure_port() and uart_resume_port() to invoke uart_rs485_config(). That allows removing calls to uart_rs485_config() from drivers' ->probe() hooks and declaring the function static. Skip any invocation of ->set_mctrl() if RS485 is enabled. RS485 has no hardware flow control, so the modem control lines are irrelevant and need not be touched. When leaving RS485 mode, reset the modem control lines to the state stored in port->mctrl. That way, UARTs which are muxed between RS485 and RS232 transceivers drive the lines correctly when switched to RS232. (serial8250_do_startup() historically raises the OUT1 modem signal because otherwise interrupts are not signaled on ancient PC UARTs, but I believe that no longer applies to modern, RS485-capable UARTs and is thus safe to be skipped.) imx.c modifies port->mctrl whenever Transmit Enable is asserted and deasserted. Stop it from doing that so port->mctrl reflects the RS232 line state. 8250_omap.c deasserts Transmit Enable on ->runtime_resume() by calling ->set_mctrl(). Because that is now a no-op in RS485 mode, amend the function to call serial8250_em485_stop_tx(). fsl_lpuart.c retrieves and applies the RS485 device tree properties after registering the UART port. Because applying now happens on registration in uart_configure_port(), move retrieval of the properties ahead of uart_add_one_port(). Link: https://lore.kernel.org/all/20220329085050.311408-1-matthias.schiffer@ew.tq-group.com/ Link: https://lore.kernel.org/all/8f538a8903795f22f9acc94a9a31b03c9c4ccacb.camel@ginzinger.com/ Fixes: d3b3404df318 ("serial: Fix incorrect rs485 polarity on uart open") Cc: stable@vger.kernel.org # v4.14+ Reported-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reported-by: Roosen Henri <Henri.Roosen@ginzinger.com> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/2de36eba3fbe11278d5002e4e501afe0ceaca039.1663863805.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_omap: Convert to use uart_xmit_advance()Andy Shevchenko2022-09-251-3/+1
| | | | | | | | | uart_xmit_advance() provides a common way on how to advance the Tx queue. Use it for the sake of unification and robustness. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220909091258.68886-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 7e2cd21e02b3 ("Merge tag 'tty-6.0-rc7' of ↵Greg Kroah-Hartman2022-09-251-0/+1
|\ | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty") into tty-next We need the tty fixes and api additions in this branch. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-20 08:53:46 +0100