Hi Jiri,
On 2/12/25 07:34, Jiri Slaby wrote:
> 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
[...]
>> 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 for your suggestion. I can come up with a patch implementing this, since
I have some hw available to test it. I'll wait a bit in case someone come with
an objection or a better idea.
Thanks,
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
