kernel/drivers/tty/serial/8250/8250_omap.c, branch linux-5.9.y

serial: 8250_omap: Avoid FIFO corruption caused by MDR1 access

2020-12-21T12:28:20Z

commit d96f04d347e4011977abdbb4da5d8f303ebd26f8 upstream. It has been observed that once per 300-1300 port openings the first transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared as "e" on the wire). It only happened if single byte has been transmitted right after port open, which means, DMA is not used for this transfer and the corruption never happened afterwards. Therefore I've carefully re-read the MDR1 errata (link below), which says "when accessing the MDR1 registers that causes a dummy under-run condition that will freeze the UART in IrDA transmission. In UART mode, this may corrupt the transferred data". Strictly speaking, omap_8250_mdr1_errataset() performs a read access and if the value is the same as should be written, exits without errata-recommended FIFO reset. A brief check of the serial_omap_mdr1_errataset() from the competing omap-serial driver showed it has no read access of MDR1. After removing the read access from omap_8250_mdr1_errataset() the data corruption never happened any more. Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20201210055257.1053028-1-alexander.sverdlin@gmail.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_omap: Switch to use platform_get_irq()

2020-06-27T14:12:45Z

platform_get_irq() provides an established error code and error message. Also, it's better to use dedicated API to retrieve Linux IRQ resource. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200618122024.87170-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

Merge tag 'tty-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2020-03-31T23:18:55Z

Pull tty/serial updates from Greg KH: "Here is the big set of TTY / Serial patches for 5.7-rc1 Lots of console fixups and reworking in here, serial core tweaks (doesn't that ever get old, why are we still creating new serial devices?), serial driver updates, line-protocol driver updates, and some vt cleanups and fixes included in here as well. All have been in linux-next with no reported issues" * tag 'tty-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (161 commits) serial: 8250: Optimize irq enable after console write serial: 8250: Fix rs485 delay after console write vt: vt_ioctl: fix use-after-free in vt_in_use() vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use virtual console tty: serial: make SERIAL_SPRD depend on COMMON_CLK tty: serial: fsl_lpuart: fix return value checking tty: serial: fsl_lpuart: move dma_request_chan() ARM: dts: tango4: Make /serial compatible with ns16550a ARM: dts: mmp*: Make the serial ports compatible with xscale-uart ARM: dts: mmp*: Fix serial port names ARM: dts: mmp2-brownstone: Don't redeclare phandle references ARM: dts: pxa*: Make the serial ports compatible with xscale-uart ARM: dts: pxa*: Fix serial port names ARM: dts: pxa*: Don't redeclare phandle references serial: omap: drop unused dt-bindings header serial: 8250: 8250_omap: Add DMA support for UARTs on K3 SoCs serial: 8250: 8250_omap: Work around errata causing spurious IRQs with DMA serial: 8250: 8250_omap: Extend driver data to pass FIFO trigger info serial: 8250: 8250_omap: Move locking out from __dma_rx_do_complete() serial: 8250: 8250_omap: Account for data in flight during DMA teardown ...

serial: 8250: 8250_omap: Add DMA support for UARTs on K3 SoCs

2020-03-24T11:25:11Z

UART on K3 SoCs has configurable RX timeout behavior (controlled via EFR2) and better DMA integration. This allows to transfer as larger amount data per DMA transfer compared to older SoCs. Add support for the same. Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20200319110344.21348-7-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman

serial: 8250: 8250_omap: Work around errata causing spurious IRQs with DMA

2020-03-24T11:25:11Z

As per Advisory 27 of AM437x Silicon errata document, Spurious UART interrupts may occur when DMA mode (FCR.DMA_MODE) is enabled. The Interrupt Controller flags that a UART interrupt has occurred; however, the associated IT_PENDING bit remains set to 1, indicating that no interrupt is pending. Acknowledge the spurious interrupts for every occurrence as workaround. Errata is applicable to all TI SoCs with this IP. Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20200319110344.21348-6-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman

serial: 8250: 8250_omap: Extend driver data to pass FIFO trigger info

2020-03-24T11:25:10Z

Although same 8250 compliant UART IP is reused across different SoC, their integration wrt DMA varies greatly across SoCs. Therefore, different SoC may need to use different FIFO trigger level for DMA event and DMA configuration parameters. Provide a way to pass this information via driver data. This is required to support UART DMA on AM654/J721e SoCs. Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20200319110344.21348-5-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman

serial: 8250: 8250_omap: Move locking out from __dma_rx_do_complete()

2020-03-24T11:25:10Z

Caller functions of __dma_rx_do_complete() already hold rx_dma_lock. Therefore move locking out of the function to avoid need to release and reacquire lock. Signed-off-by: Peter Ujfalusi Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20200319110344.21348-4-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman

serial: 8250: 8250_omap: Account for data in flight during DMA teardown

2020-03-24T11:25:10Z

Take into account data stuck in DMA internal buffers before pushing data to higher layer. dma_tx_state has "in_flight_bytes" member that provides this information. Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20200319110344.21348-3-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman

serial: 8250: 8250_omap: Terminate DMA before pushing data on RX timeout

2020-03-24T11:25:10Z

Terminate and flush DMA internal buffers, before pushing RX data to higher layer. Otherwise, this will lead to data corruption, as driver would end up pushing stale buffer data to higher layer while actual data is still stuck inside DMA hardware and has yet not arrived at the memory. While at that, replace deprecated dmaengine_terminate_all() with dmaengine_terminate_async(). Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20200319110344.21348-2-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_omap: Fix sleeping function called from invalid context during probe

2020-03-24T11:25:09Z

When booting j721e the following bug is printed: [ 1.154821] BUG: sleeping function called from invalid context at kernel/sched/completion.c:99 [ 1.154827] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 12, name: kworker/0:1 [ 1.154832] 3 locks held by kworker/0:1/12: [ 1.154836] #0: ffff000840030728 ((wq_completion)events){+.+.}, at: process_one_work+0x1d4/0x6e8 [ 1.154852] #1: ffff80001214fdd8 (deferred_probe_work){+.+.}, at: process_one_work+0x1d4/0x6e8 [ 1.154860] #2: ffff00084060b170 (&dev->mutex){....}, at: __device_attach+0x38/0x138 [ 1.154872] irq event stamp: 63096 [ 1.154881] hardirqs last enabled at (63095): [] _raw_spin_unlock_irqrestore+0x70/0x78 [ 1.154887] hardirqs last disabled at (63096): [] _raw_spin_lock_irqsave+0x28/0x80 [ 1.154893] softirqs last enabled at (62254): [] _stext+0x488/0x564 [ 1.154899] softirqs last disabled at (62247): [] irq_exit+0x114/0x140 [ 1.154906] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.0-rc6-next-20200318-00094-g45e4089b0bd3 #221 [ 1.154911] Hardware name: Texas Instruments K3 J721E SoC (DT) [ 1.154917] Workqueue: events deferred_probe_work_func [ 1.154923] Call trace: [ 1.154928] dump_backtrace+0x0/0x190 [ 1.154933] show_stack+0x14/0x20 [ 1.154940] dump_stack+0xe0/0x148 [ 1.154946] ___might_sleep+0x150/0x1f0 [ 1.154952] __might_sleep+0x4c/0x80 [ 1.154957] wait_for_completion_timeout+0x40/0x140 [ 1.154964] ti_sci_set_device_state+0xa0/0x158 [ 1.154969] ti_sci_cmd_get_device_exclusive+0x14/0x20 [ 1.154977] ti_sci_dev_start+0x34/0x50 [ 1.154984] genpd_runtime_resume+0x78/0x1f8 [ 1.154991] __rpm_callback+0x3c/0x140 [ 1.154996] rpm_callback+0x20/0x80 [ 1.155001] rpm_resume+0x568/0x758 [ 1.155007] __pm_runtime_resume+0x44/0xb0 [ 1.155013] omap8250_probe+0x2b4/0x508 [ 1.155019] platform_drv_probe+0x50/0xa0 [ 1.155023] really_probe+0xd4/0x318 [ 1.155028] driver_probe_device+0x54/0xe8 [ 1.155033] __device_attach_driver+0x80/0xb8 [ 1.155039] bus_for_each_drv+0x74/0xc0 [ 1.155044] __device_attach+0xdc/0x138 [ 1.155049] device_initial_probe+0x10/0x18 [ 1.155053] bus_probe_device+0x98/0xa0 [ 1.155058] deferred_probe_work_func+0x74/0xb0 [ 1.155063] process_one_work+0x280/0x6e8 [ 1.155068] worker_thread+0x48/0x430 [ 1.155073] kthread+0x108/0x138 [ 1.155079] ret_from_fork+0x10/0x18 To fix the bug we need to first call pm_runtime_enable() prior to any pm_runtime calls. Reported-by: Tomi Valkeinen Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20200320125200.6772-1-peter.ujfalusi@ti.com Signed-off-by: Greg Kroah-Hartman