A fallback baud rate was derived from old termios but got never applied
to (new/current) termios. Old termios is dropped once ->set_termios()
call chain completes, only termios persists the values. Encode also the
old baud rate into termios.
Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate")
Signed-off-by: Ilpo Järvinen <[email protected]>
---
drivers/tty/serial/mvebu-uart.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
index 0429c2a54290..12a79018697f 100644
--- a/drivers/tty/serial/mvebu-uart.c
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -592,10 +592,9 @@ static void mvebu_uart_set_termios(struct uart_port *port,
if (old)
baud = uart_get_baud_rate(port, old, NULL,
min_baud, max_baud);
- } else {
- tty_termios_encode_baud_rate(termios, baud, baud);
- uart_update_timeout(port, termios->c_cflag, baud);
}
+ tty_termios_encode_baud_rate(termios, baud, baud);
+ uart_update_timeout(port, termios->c_cflag, baud);
/* Only the following flag changes are supported */
if (old) {
--
tg: (f287f971e256..) fix/mvebu-apply-old-baud (depends on: tty-next)
On Tuesday 28 June 2022 11:51:36 Pali Rohár wrote:
> On Tuesday 28 June 2022 12:41:55 Ilpo Järvinen wrote:
> > A fallback baud rate was derived from old termios but got never applied
> > to (new/current) termios. Old termios is dropped once ->set_termios()
> > call chain completes, only termios persists the values. Encode also the
> > old baud rate into termios.
> >
> > Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate")
> > Signed-off-by: Ilpo Järvinen <[email protected]>
>
> Hello! Could you explain a bit more what is this patch fixing? I have
> not caught it yet. Do you have a test scenario which can demonstrate
> this issue? Because I have tested this driver more deeply (on Mox
> and Espressobin) and I have not seen any remaining issue with reporting
> incorrect baudrate.
Ou, now I see where is the issue. Patch which I tested and which fixes
reporting baudrate is not in kernel tree yet and it looks like I totally
forgot to sent it to ML. I will send it. Sorry for confusion.
> > ---
> > drivers/tty/serial/mvebu-uart.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
> > index 0429c2a54290..12a79018697f 100644
> > --- a/drivers/tty/serial/mvebu-uart.c
> > +++ b/drivers/tty/serial/mvebu-uart.c
> > @@ -592,10 +592,9 @@ static void mvebu_uart_set_termios(struct uart_port *port,
> > if (old)
> > baud = uart_get_baud_rate(port, old, NULL,
> > min_baud, max_baud);
> > - } else {
> > - tty_termios_encode_baud_rate(termios, baud, baud);
> > - uart_update_timeout(port, termios->c_cflag, baud);
> > }
> > + tty_termios_encode_baud_rate(termios, baud, baud);
> > + uart_update_timeout(port, termios->c_cflag, baud);
> >
> > /* Only the following flag changes are supported */
> > if (old) {
> >
> > --
> > tg: (f287f971e256..) fix/mvebu-apply-old-baud (depends on: tty-next)
On Tuesday 28 June 2022 12:41:55 Ilpo Järvinen wrote:
> A fallback baud rate was derived from old termios but got never applied
> to (new/current) termios. Old termios is dropped once ->set_termios()
> call chain completes, only termios persists the values. Encode also the
> old baud rate into termios.
>
> Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate")
> Signed-off-by: Ilpo Järvinen <[email protected]>
Hello! Could you explain a bit more what is this patch fixing? I have
not caught it yet. Do you have a test scenario which can demonstrate
this issue? Because I have tested this driver more deeply (on Mox
and Espressobin) and I have not seen any remaining issue with reporting
incorrect baudrate.
> ---
> drivers/tty/serial/mvebu-uart.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
> index 0429c2a54290..12a79018697f 100644
> --- a/drivers/tty/serial/mvebu-uart.c
> +++ b/drivers/tty/serial/mvebu-uart.c
> @@ -592,10 +592,9 @@ static void mvebu_uart_set_termios(struct uart_port *port,
> if (old)
> baud = uart_get_baud_rate(port, old, NULL,
> min_baud, max_baud);
> - } else {
> - tty_termios_encode_baud_rate(termios, baud, baud);
> - uart_update_timeout(port, termios->c_cflag, baud);
> }
> + tty_termios_encode_baud_rate(termios, baud, baud);
> + uart_update_timeout(port, termios->c_cflag, baud);
>
> /* Only the following flag changes are supported */
> if (old) {
>
> --
> tg: (f287f971e256..) fix/mvebu-apply-old-baud (depends on: tty-next)
On Tue, Jun 28, 2022 at 1:39 PM Andy Shevchenko
<[email protected]> wrote:
> On Tue, Jun 28, 2022 at 12:01 PM Pali Rohár <[email protected]> wrote:
> > On Tuesday 28 June 2022 11:51:36 Pali Rohár wrote:
...
> > Ou, now I see where is the issue. Patch which I tested and which fixes
> > reporting baudrate is not in kernel tree yet and it looks like I totally
> > forgot to sent it to ML. I will send it. Sorry for confusion.
>
> Shouldn't the Ilpo's applied anyway to fix the current code base?
Ah, now I understand that your patch is a fix. Sorry for the noise.
--
With Best Regards,
Andy Shevchenko
On Tue, Jun 28, 2022 at 12:01 PM Pali Rohár <[email protected]> wrote:
> On Tuesday 28 June 2022 11:51:36 Pali Rohár wrote:
> > On Tuesday 28 June 2022 12:41:55 Ilpo Järvinen wrote:
> > > A fallback baud rate was derived from old termios but got never applied
> > > to (new/current) termios. Old termios is dropped once ->set_termios()
> > > call chain completes, only termios persists the values. Encode also the
> > > old baud rate into termios.
> > >
> > > Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate")
> > > Signed-off-by: Ilpo Järvinen <[email protected]>
> >
> > Hello! Could you explain a bit more what is this patch fixing? I have
> > not caught it yet. Do you have a test scenario which can demonstrate
> > this issue? Because I have tested this driver more deeply (on Mox
> > and Espressobin) and I have not seen any remaining issue with reporting
> > incorrect baudrate.
>
> Ou, now I see where is the issue. Patch which I tested and which fixes
> reporting baudrate is not in kernel tree yet and it looks like I totally
> forgot to sent it to ML. I will send it. Sorry for confusion.
Shouldn't the Ilpo's applied anyway to fix the current code base?
--
With Best Regards,
Andy Shevchenko
On Tuesday 28 June 2022 13:40:28 Andy Shevchenko wrote:
> On Tue, Jun 28, 2022 at 1:39 PM Andy Shevchenko
> <[email protected]> wrote:
> > On Tue, Jun 28, 2022 at 12:01 PM Pali Rohár <[email protected]> wrote:
> > > On Tuesday 28 June 2022 11:51:36 Pali Rohár wrote:
>
> ...
>
> > > Ou, now I see where is the issue. Patch which I tested and which fixes
> > > reporting baudrate is not in kernel tree yet and it looks like I totally
> > > forgot to sent it to ML. I will send it. Sorry for confusion.
> >
> > Shouldn't the Ilpo's applied anyway to fix the current code base?
>
> Ah, now I understand that your patch is a fix. Sorry for the noise.
Yes, my patch fixes the issue which Ilpo described and handles also errors:
https://lore.kernel.org/linux-serial/[email protected]/