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@xxxxxxxxxxxxxxx>
[ 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@xxxxxxxxxxxx>
Reviewed-by: Jiri Slaby <jirislaby@xxxxxxxxxx>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
Link: https://lore.kernel.org/r/20230117090358.4796-9-
ilpo.jarvinen@xxxxxxxxxxxxxxx
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
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.
--
Thanks,
Sasha
