i can observe a very similar situation, but with a litte different
configuration. This is how i can trigger the situation very quickly:
1) open the port
2) send 1 byte out
3) close the port
Hi Eberhard
Thanks for chiming in. I assume this is all in rs485 mode, no switching
to rs232 and back involved?
Yes, no mode switching is involved here. Only rs485 mode.
Setting ->tx_state = SEND in imx_uart_shutdown() helps for my issue
(and should be ok IMHO).
[I assume you mean tx_state = OFF]. Yes, I suppose doing that would be > ok, but I'm not sure it's a complete fix. In my simple test cast, I have
Oh, yes, sorry my mistake!
I really meant ->tx_state = OFF as you expected in your comment
separate programs invoked to do the I/O and do the mode switch, but in a
real scenario, I'd expect the application itself to just open the device
once, and then do I/O and mode switching as appropriate for the
application logic, and I don't think uart_shutdown would then ever get
called.
Switching between rs232 mode and rs485 mode on an open port is a special
use case in my experience. But it's valid and introduces some extra
complexity. As you stated, for this use case setting ->tx_state = OFF in
imx_uart_shutdown() does not really help.
Indeed, that's an extra complication. Adding two hrtimer_try_to_cancel()
in shutdown would probably not hurt, along with setting tx_state OFF.
I wonder if at least mode switching should simply be disallowed (-EBUSY)
if tx_state is anything but OFF.
Seems there are various issues in ->tx_state handling and transmitter
timing in this driver!
Best Regards
Eberhard
