#
0863bffd |
| 14-Aug-2024 |
Griffin Kroah-Hartman <griffin@kroah.com> |
Revert "serial: 8250_omap: Set the console genpd always on if no console suspend"
This reverts commit 68e6939ea9ec3d6579eadeab16060339cdeaf940.
Kevin reported that this causes a crash during suspen
Revert "serial: 8250_omap: Set the console genpd always on if no console 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>
show more ...
|
#
7c199bd2 |
| 07-Aug-2024 |
Markus Schneider-Pargmann <msp@baylibre.com> |
serial: 8250: omap: Parse DT wakeup-source proerty
If the wakeup-source property is present, enable wakeup from this device.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by:
serial: 8250: omap: Parse DT wakeup-source proerty
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>
show more ...
|
#
4179df77 |
| 07-Aug-2024 |
Markus Schneider-Pargmann <msp@baylibre.com> |
serial: 8250: omap: Set wakeup capable, do not enable
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 enab
serial: 8250: omap: Set wakeup capable, do not enable
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>
show more ...
|
#
35e648a1 |
| 07-Aug-2024 |
Markus Schneider-Pargmann <msp@baylibre.com> |
serial: 8250: omap: Cleanup on error in request_irq
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.
serial: 8250: omap: Cleanup on error in request_irq
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>
show more ...
|
#
704c2c36 |
| 07-Aug-2024 |
Markus Schneider-Pargmann <msp@baylibre.com> |
serial: 8250: omap: Remove unused wakeups_enabled
This field seems to be unused for quite some time already. Remove it.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Kevi
serial: 8250: omap: Remove unused wakeups_enabled
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>
show more ...
|
#
c128a1b0 |
| 25-Jun-2024 |
Udit Kumar <u-kumar1@ti.com> |
serial: 8250_omap: Fix Errata i2310 with RX FIFO level check
Errata i2310[0] says, Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interr
serial: 8250_omap: Fix Errata i2310 with RX FIFO level check
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>
show more ...
|
#
9d141c1e |
| 19-Jun-2024 |
Udit Kumar <u-kumar1@ti.com> |
serial: 8250_omap: Implementation of Errata i2310
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, the
serial: 8250_omap: Implementation of Errata i2310
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>
show more ...
|
#
a8045157 |
| 07-Mar-2024 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
serial: 8250_omap: Remove unused of_gpio.h
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.shevchen
serial: 8250_omap: Remove unused of_gpio.h
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>
show more ...
|
#
1788cf6a |
| 05-Apr-2024 |
Jiri Slaby (SUSE) <jirislaby@kernel.org> |
tty: serial: switch from circ_buf to kfifo
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 pl
tty: serial: switch from circ_buf to kfifo
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>
show more ...
|
#
9054605a |
| 05-Apr-2024 |
Jiri Slaby (SUSE) <jirislaby@kernel.org> |
tty: 8250_omap: use dmaengine_prep_slave_sg()
This is a preparatory for the serial-to-kfifo switch. kfifo understands only scatter-gatter approach, so switch to that.
No functional change intended,
tty: 8250_omap: use dmaengine_prep_slave_sg()
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>
show more ...
|
#
664f5d03 |
| 04-Mar-2024 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
serial: 8250_omap: Switch to use uart_read_port_properties()
Since we have now a common helper to read port properties use it instead of sparse home grown solution.
Signed-off-by: Andy Shevchenko <
serial: 8250_omap: Switch to use uart_read_port_properties()
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>
show more ...
|
#
8973ab7a |
| 31-Oct-2023 |
Ronald Wahl <ronald.wahl@raritan.com> |
serial: 8250: 8250_omap: Clear UART_HAS_RHR_IT_DIS bit
This fixes commit 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable") which unfortunately set the UART_HAS_RHR_IT_D
serial: 8250: 8250_omap: Clear UART_HAS_RHR_IT_DIS bit
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>
show more ...
|
#
c6bb0574 |
| 01-Nov-2023 |
Ronald Wahl <ronald.wahl@raritan.com> |
serial: 8250: 8250_omap: Do not start RX DMA on THRI interrupt
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: 8250_omap: Do not start RX DMA on THRI interrupt
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>
show more ...
|
#
7e1efdf8 |
| 10-Nov-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
serial: 8250: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error
serial: 8250: Convert to platform remove callback returning void
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>
show more ...
|
#
ad90d035 |
| 10-Nov-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed
Returning an error code from .remove() makes the driver core emit the little helpful error message:
remove cal
serial: 8250: omap: Don't skip resource freeing if 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>
show more ...
|
#
68e6939e |
| 17-Oct-2023 |
Thomas Richard <thomas.richard@bootlin.com> |
serial: 8250_omap: Set the console genpd always on if no console suspend
If the console suspend is disabled, the genpd of the console shall not be powered-off during suspend. Set the flag GENPD_FLAG
serial: 8250_omap: Set the console genpd always on if no console suspend
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>
show more ...
|
#
8700a7ea |
| 04-Oct-2023 |
Tony Lindgren <tony@atomide.com> |
serial: 8250_omap: Drop pm_runtime_irq_safe()
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 paren
serial: 8250_omap: Drop pm_runtime_irq_safe()
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>
show more ...
|
#
560706ef |
| 26-Sep-2023 |
Tony Lindgren <tony@atomide.com> |
serial: 8250_omap: Fix errors with no_console_suspend
We now get errors on system suspend if no_console_suspend is set as reported by Thomas. The errors started with commit 20a41a62618d ("serial: 82
serial: 8250_omap: Fix errors with no_console_suspend
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>
show more ...
|
#
e4a13758 |
| 14-Sep-2023 |
Thomas Gleixner <tglx@linutronix.de> |
serial: 8250_omap: Use port lock wrappers
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,
serial: 8250_omap: Use port lock wrappers
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>
show more ...
|
#
29e5c442 |
| 24-Jul-2023 |
Rob Herring <robh@kernel.org> |
tty: Explicitly include correct DT includes
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 mer
tty: Explicitly include correct DT includes
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>
show more ...
|
#
20a41a62 |
| 14-Jun-2023 |
Tony Lindgren <tony@atomide.com> |
serial: 8250_omap: Use force_suspend and resume for system suspend
We should not rely on autosuspend timeout for system suspend. Instead, let's use force_suspend and force_resume functions. Otherwis
serial: 8250_omap: Use force_suspend and resume for system suspend
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>
show more ...
|
#
ae62c49c |
| 17-May-2023 |
Arnd Bergmann <arnd@arndb.de> |
serial: 8250: omap: convert to modern PM ops
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_oma
serial: 8250: omap: convert to modern PM ops
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>
show more ...
|
#
c53aab20 |
| 15-May-2023 |
Geert Uytterhoeven <geert@linux-m68k.org> |
serial: 8250: omap: Move uart_write() inside PM section
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 [-
serial: 8250: omap: Move uart_write() inside PM section
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>
show more ...
|
#
d0b309a5 |
| 25-May-2023 |
John Ogness <john.ogness@linutronix.de> |
serial: 8250: synchronize and annotate UART_IER access
The UART_IER register is modified twice by each console write (serial8250_console_write()) under the port lock. Any driver code that accesses U
serial: 8250: synchronize and annotate UART_IER access
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>
show more ...
|
#
25614735 |
| 25-May-2023 |
John Ogness <john.ogness@linutronix.de> |
serial: 8250: lock port for UART_IER access in omap8250_irq()
omap8250_irq() accesses UART_IER. This register is modified twice by each console write (serial8250_console_write()) under the port lock
serial: 8250: lock port for UART_IER access in omap8250_irq()
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>
show more ...
|