AM5749: tty serial 8250 omap driver crash

[Romain Naour <romain.naour@smile.fr>]

Hi,

I noticed a kernel crash while opening a serial port connected to a GPS device.
I initially reported the issue to the TI forum [1] but the issue seems related
to the 8250_omap driver.

Using the Linux kernel 4.19-rt provided by the TISDK 6.03, I was able to use a
GPS device connected to the uart4 of the AM5749 device (custom board).
As a basic test I'm using gpscat, gpsmon or gpsctl to open the /dev/gnss0 interface.

Note: The UART4 doesn't use RTS/CTS signals, Only Tx and Rx are defined in the
pinmux project (SW flow control).

Now I'm using a kernel v5.10.87-rt59 from the ti-linux branch [2] but I noticed
a kernel crash while opening /dev/gnss0:

__irq_svc from mem_serial_in+0x4/0x1c
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
ttyport_open from serdev_device_open+0x28/0xb0
serdev_device_open from gnss_serial_open+0x14/0x98
gnss_serial_open from gnss_open+0x68/0xb4
gnss_open from chrdev_open+0xa8/0x1a0
chrdev_open from do_dentry_open+0x110/0x3ec
do_dentry_open from path_openat+0xb64/0xd6c
path_openat from do_filp_open+0x80/0xf4
do_filp_open from do_sys_openat2+0x304/0x3d8
do_sys_openat2 from do_sys_open+0x7c/0xcc
do_sys_open from ret_fast_syscall+0x0/0x4c

It's not 100% reproducible but if you try 10 times the same command, the kernel
will crash.

It seems that the driver fail to read the UART_LCR register from
omap8250_set_mctrl():

"lcr = serial_in(up, UART_LCR);"

PC is at mem_serial_in+0x2c/0x30
LR is at omap8250_set_mctrl+0x48/0xb0

The problem only occurs with a -rt kernel, I tried with several kernel version:
5.10-rt, 5.15-rt and 5.17-rt.

I'm not able to reproduce the issue with a standard kernel.

While looking at the git history, I noticed this commit [3] about "flakey idling
of uarts and stop using swsup_sidle_act".

So I removed the SYSC_QUIRK for uart IP revision 0x50411e03 and it fixed my issue.

Before that, I tried to revert to SYSC_QUIRK_SWSUP_SIDLE_ACT but the kernel
crash again. Adding "ti,no-idle" to the ti,sysc node parent of uart4 doesn't
solve the issue either.

AFIU, the issue is related to auto suspend (smart-idle) present in uart IPs used
by TI in Sitara AM57xx cpu devices.

The problem is that the uart4 is in idle mode by default since it's not a serial
console.
 As soon as we use gpsmon on /dev/gnss0, the uart IP is switched to operational mode
.
The SYSC_QUIRK is reading the IP revision of the uart4 at address 0x4806E050.

Reading at this address with devmem2 while the gpsmon is not started trigger a
kernel oops:

devmem2 0x4806E050 w



To read this register correctly we have to start gpsmon first (opening /dev/gnss0).

Is the SYSC_QUIRK for omap4 still needed ? Is it safe to remove it ?
It seems this issue was introduced while dropping the legacy platform data
(between 4.19 and 5.4 kernels).

[1]
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1074192/am5749-tty-serial-8250-omap-driver-crash
[2]
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-linux-5.10.y&id=892cf512e34e60123e043f88bbb80
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0d83aec6e0102e014eafdd453bdbc61b4d193029

Best regards,
Romain