lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAn10+fRb8VXnDEsSuCj782rp43ZEeov2yXnB2pYxXGNc-2niQ@mail.gmail.com>
Date: Tue, 30 Sep 2025 19:20:48 +0200
From: Marnix Rijnart <marnix.rijnart@...ll.eu>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>, 
	LKML <linux-kernel@...r.kernel.org>, linux-serial <linux-serial@...r.kernel.org>, 
	regressions@...ts.linux.dev
Subject: Re: [REGRESSION][PATCH] serial: 8250_pci: Fix broken RS485 for F81504/508/512

This is my first interaction with the kernel community, so I did my
best to read up on the expected practices but maybe I missed
something.

I didn't add a Fixes tag for commit 4afeced because it doesn't cause
the bug by itself, it's the interaction between it and an older commit
(456d523) that create the issue together. What's the right way to tag
this?

I didn't Cc stable because I understood this to be only required for
point release regressions within a stable series
(https://docs.kernel.org/admin-guide/reporting-regressions.html).
Release 6.8 introduced this regression. Should I still Cc them?

If these tags need to added, what's the best way to do so? Resubmit
the patch (as a v2)?

Thanks,
Marnix

Op di 30 sep 2025 om 13:32 schreef Ilpo Järvinen
<ilpo.jarvinen@...ux.intel.com>:
>
> On Wed, 24 Sep 2025, Marnix Rijnart wrote:
>
> > Commit 4afeced ("serial: core: fix sanitizing check for RTS settings")
> > introduced a regression making it impossible to unset
> > SER_RS485_RTS_ON_SEND from userspace if SER_RS485_RTS_AFTER_SEND is
> > unsupported. Because these devices need RTS to be low on TX (fecf27a)
> > they are effectively broken.
> >
> > The hardware supports both RTS_ON_SEND and RTS_AFTER_SEND,
> > so fix this by announcing support for SER_RS485_RTS_AFTER_SEND,
> > similar to commit 068d35a.
> >
> > Signed-off-by: Marnix Rijnart <marnix.rijnart@...ll.eu>
>
> The Fixes tag is missing?
>
> (And Cc stable tag will be necessary as well).
>
> > ---
> >  drivers/tty/serial/8250/8250_pci.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
> > index 152f914c599d..a9da222bd174 100644
> > --- a/drivers/tty/serial/8250/8250_pci.c
> > +++ b/drivers/tty/serial/8250/8250_pci.c
> > @@ -1645,7 +1645,7 @@ static int pci_fintek_rs485_config(struct uart_port *port, struct ktermios *term
> >  }
> >
> >  static const struct serial_rs485 pci_fintek_rs485_supported = {
> > -     .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND,
> > +     .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND | SER_RS485_RTS_AFTER_SEND,
> >       /* F81504/508/512 does not support RTS delay before or after send */
> >  };
> >
> >
>
> --
>  i.
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ