Greg Kroah-Hartman wrote on Mon, Oct 10, 2022 at 08:38:07AM +0200:
Thanks for this fix! We also noticed rs485 DE was initially wrong last week and I noticed this when I was about to send a patch that just inverted the SER_RS485_RTS_AFTER_SEND check in uart_configure_port, but after reading the commit message here it's a lot more complicated than that depending on the serial driver... (fixing commit 2dd8a74fddd2 ("serial: core: Initialize rs485 RTS polarity already on probe"), but it's actually the same problem in the opposite direction)
Unfortunately you've marked this for v4.14+ stable, but it doesn't even apply to 5.19.14 due to (at least) commit d8fcd9cfbde5 ("serial: core: move sanitizing of RS485 delays into own function"), so it hasn't been picked up yet; since quite a bit of code was cleaned up/moved one will need to pay a bit attention when doing that.
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?
If that sounds too complicated we could probably just revert a handful of serial_core/rs485 commits, but going forward sounds more future-proof to me.
Thanks! (nothing below, leaving quote for stable@)
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
</formletter>
Yes, it does not apply. I've just added stable@ in cc so you're aware that 5.10 and 5.15 still have a problem with the serial code (and in case you have an opinion between trying to backport this big patch or reverting a bunch of older ones)
The quote is just context.
I can try to backport it and send it properly if Lukas doesn't have time, but it doesn't hurt to discuss first.
Thanks,