Hi, On Sun, 2 Jun 2024 at 19:24, Doug Brown <doug@xxxxxxxxxxxxx> wrote: > > Hi Jonas, > > >> On Mon, 20 May 2024 at 08:41, Jiri Slaby <jirislaby@xxxxxxxxxx> wrote: > >>> > >>> Perhaps, it should be reverted and the affected driver should just pass > >>> UART_TX_NOSTOP instead? > >>> > >>>> uart_port_tx_limited(&up->port, ch, up->port.fifosize / 2, > >>>> true, > >>>> serial_out(up, UART_TX, ch), > Does the bcm63xx_uart driver work correctly if 7bfb915a597a is reverted > and UART_TX_NOSTOP is used instead? > > I was able to further confirm on hardware (BeagleBoard) that omap-serial > is also broken after 7bfb915a597a. I'm trying to figure out how to > safely revert it while also allowing bcm63xx to continue to work properly. So I went through all users of uart_port_tx(_limited()), and expectedly most do just disable the IRQ (or do nothing) in their stop_tx() call back. The notable exceptions I could identify are: - bcm63xx_uart: disables the emitter as well - mxs-uart: disables the emitter (introduced and uses UART_TX_NOSTOP) - sprd_serial: stops alls dma transfers as well - atmel_serial: stops dma and disables emitter as well I suspect sprd_serial and atmel_serial to not work properly with the old behavior, but I have no devices where I could test this. There are a few more exceptions in those that do not use uart_port_tx(_limited()), like I've seen drivers blocking in stop_tx() until the FIFO is empty. Not sure if that is expected. The quick solutions for bcm63xx_uart to either pass UART_TX_NOSTOP [1], or make stop_tx() (and start_tx()) not touch the emitter (or revert the uart_port_tx_limited() usage). Regardless of the chosen quick fix, it feels like stop_tx() is the wrong thing to use for uart_port_tx(), and just happened to do the right thing for the majority or drivers. But the correct function (something along "done submitting tx") also doesn't exist. But I'm no maintainer for tty/serial, nor do I have much (intimate) knowledge there. This is just from looking at it from the outside, and my thoughts may very well be wrong. [1] https://lore.kernel.org/lkml/20240225151426.1342285-1-jonas.gorski@xxxxxxxxx/ Best Regards, Jonas
