On Tue, Oct 29, 2024 at 12:40:54PM +0100, Jiri Slaby wrote:
On 29. 10. 24, 12:26, Sasha Levin wrote:
On Tue, Oct 29, 2024 at 06:59:55AM +0100, Jiri Slaby wrote:
On 28. 10. 24, 7:25, Greg Kroah-Hartman wrote:
6.1-stable review patch. If anyone has any objections, please let me know.
From: Ilpo Järvinen ilpo.jarvinen@linux.intel.com
[ Upstream commit 0388a152fc5544be82e736343496f99c4eef8d62 ]
Convert status parameter for ->dcd_change() and uart_handle_dcd_change() to bool which matches to how the parameter is used.
Rename status to active to better describe what the parameter means.
Acked-by: Rodolfo Giometti giometti@enneenne.com Reviewed-by: Jiri Slaby jirislaby@kernel.org Signed-off-by: Ilpo Järvinen ilpo.jarvinen@linux.intel.com Link: https://lore.kernel.org/r/20230117090358.4796-9- ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Stable-dep-of: 40d7903386df ("serial: imx: Update mctrl old_status on RTSD interrupt")
As I wrote earlier, why is this Stable-dep-of that one?
Here's the dependency chain:
40d7903386df ("serial: imx: Update mctrl old_status on RTSD interrupt") 968d64578ec9 ("serial: Make uart_handle_cts_change() status param bool active") 0388a152fc55 ("tty/serial: Make ->dcd_change()+uart_handle_dcd_change() status bool active")
If you go to 6.1.y, and try to apply them in that order you'll see that it applies cleanly. If you try to apply just the last one you'll hit a conflict.
Oh, well, so instead of taking two irrelevant and potentially dangerous patches (0388a152fc55 + 968d64578ec9), this simple context fix should have been in place:
uart_handle_cts_change(&sport->port, !!usr1);
uart_handle_cts_change(&sport->port, usr1);Right?
No :)
1. If we make changes like the above, future patches that touch that code simply fail to backport, no one cares enough to fix them up, and older trees stop getting those fixes. Staying aligned with upstream means less work in the longer term.
2. Is that everything that's needed for the fix? Maybe? I don't know... I'm not a TTY expert, I'm not sure that that fix is correct, nor do I have no way to test that. Do you really trust me that much around your subsystem? :)
3. We simply don't scale to doing this for every conflict over the (too many) trees we support. At some point we need to trust our automation, CI, and testers to catch issues with the "extra" patches we backport.