Re: [PATCH 6.1 068/137] tty/serial: Make ->dcd_change()+uart_handle_dcd_change() status bool active

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux