On 11. 02. 25, 19:09, Alexis Lothoré wrote:
Hello,
I am currently working on a device driver for a serial device, on a setup
involving one of the standard UART from SAMA5D27 (not the flexcom one), as well
as two additional gpios for flow control (CTS/RTS). I can reliably reproduce a
splat when trying to enable/disable flow control on the target uart (through
serdev_device_set_flow_control). I am basing my work on top of the current
wireless-next tree:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:738
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0
preempt_count: 1, expected: 0
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [<c01588f0>] copy_process+0x1c4c/0x7bec
softirqs last enabled at (0): [<c0158944>] copy_process+0x1ca0/0x7bec
softirqs last disabled at (0): [<00000000>] 0x0
CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74
Hardware name: Atmel SAMA5
Workqueue: hci0 hci_power_on [bluetooth]
Call trace:
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x44/0x70
dump_stack_lvl from __might_resched+0x38c/0x598
__might_resched from disable_irq+0x1c/0x48
disable_irq from mctrl_gpio_disable_ms+0x74/0xc0
mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4
atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8
atmel_set_termios from uart_change_line_settings+0x15c/0x994
uart_change_line_settings from uart_set_termios+0x2b0/0x668
uart_set_termios from tty_set_termios+0x600/0x8ec
tty_set_termios from ttyport_set_flow_control+0x188/0x1e0
ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc]
wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth]
hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth]
hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth]
hci_power_on [bluetooth] from process_one_work+0x998/0x1a38
process_one_work from worker_thread+0x6e0/0xfb4
worker_thread from kthread+0x3d4/0x484
kthread from ret_from_fork+0x14/0x28
Exception stack(0xd095bfb0 to 0xd095bff8)
bfa0: 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
My current understanding is that the issue is around atmel_set_termios which
disables interrupts (through uart_port_lock_irqsave), but then calls
mctrl_gpio_disable_ms, which in turn calls disable_irq, which can not be called
in atomic context. It looks like the issue may have been around for quite some
time, but it may have started to appear because of disable_irq having been
marked with might_sleep: see commit 17549b0f184d ("genirq: Add might_sleep() to
disable_irq()") ?
We likely want to introduce 'bool sync' param to
mctrl_gpio_disable_ms(). It would call disable_irq() or
disable_irq_nosync() appropriately. As for example, imx_uart_shutdown()
wants to sync, but serial8250_disable_ms() and atmel_disable_ms() do not.
But I am no expert in this mctrl land.
thanks,
--
js
suse labs
