Lukas Wunner wrote on Mon, Oct 10, 2022 at 10:53:05AM +0200:
Unfortunately you've marked this for v4.14+ stable, but it doesn't even apply to 5.19.14
[...]
What would you like to do for stable branches? Would you be able to send a patch that applies on older 5.10 and 5.15 where commit d3b3404df318 ("serial: Fix incorrect rs485 polarity on uart open") has been backported?
Greg will try to apply it to stable kernels (probably after the merge window closes) and send an e-mail that it failed. I was going to wait for that to happen and then look into backporting the patch.
Ah, sorry for rushing you here -- I got tricked by the git committer date but that doesn't mean the merge commit was that old, I hadn't noticed this just got in.
Basically what needs to be done is replace calls to uart_rs485_config() with a direct invocation of port->rs485_config(). Plus carefully checking that nothing is missing or breaks. That's probably simpler than just backporting additional patches or reverting stuff. If you want to take a stab at it, go ahead. :)
The only hardware I have is ims and your patch touches at quite a few of the drivers, I'm not really in a good position to check anything there but I can give it a stab tomorrow or Wed
By the way that just made me check the imx code, but if I am to trust that set_mctrl is never called with RS485 enabled and rs485_config is only called when it is enabled should the SER_RS485_ENABLED checks be removed there, or did I misunderstand something and it's still useful?
(I wouldn't know if the rs232 hardware flags have any impact on rs485 actual control but I'll trust you on this and that nothing ever calls set_mctrl when rs485 is enabled... I would actually have said that rts_active/inactive should keep setting port->mctrl precisely for the cases where both are muxed as you'll otherwise unreliably enable/disable RTS based on the state the last time was when get_mctrl was called; but I haven't seen this done so it doesn't really matter to me)
Thanks,