devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Max Filippov <jcmvbkbc@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	 linux-serial <linux-serial@vger.kernel.org>,
	devicetree@vger.kernel.org,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 Jiri Slaby <jirislaby@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	 Conor Dooley <conor+dt@kernel.org>
Subject: Re: [PATCH v4 1/5] serial: core: tidy invalid baudrate handling in uart_get_baud_rate
Date: Fri, 29 Sep 2023 09:34:07 +0300 (EEST)	[thread overview]
Message-ID: <69902af8-103-38a8-c438-87f7a047497@linux.intel.com> (raw)
In-Reply-To: <20230928151631.149333-2-jcmvbkbc@gmail.com>

On Thu, 28 Sep 2023, Max Filippov wrote:

> uart_get_baud_rate has input parameters 'min' and 'max' limiting the
> range of acceptable baud rates from the caller's perspective. If neither
> current or old termios structures have acceptable baud rate setting and
> 9600 is not in the min/max range either the function returns 0 and
> issues a warning.
> However for a UART that does not support speed of 9600 baud this is
> expected behavior.
> Clarify that 0 can be (and always could be) returned from the
> uart_get_baud_rate. Don't issue a warning in that case.
> Move the warinng to the uart_get_divisor instead, which is often called
> with the uart_get_baud_rate return value.
> 
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> ---
> Changes v3->v4:
> - drop WARN_ON from uart_get_divisor()
> 
>  drivers/tty/serial/serial_core.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 7bdc21d5e13b..3f130fe9f1a0 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -431,7 +431,7 @@ EXPORT_SYMBOL(uart_update_timeout);
>   * baud.
>   *
>   * If the new baud rate is invalid, try the @old termios setting. If it's still
> - * invalid, we try 9600 baud.
> + * invalid, we try 9600 baud. If that is also invalid 0 is returned.
>   *
>   * The @termios structure is updated to reflect the baud rate we're actually
>   * going to be using. Don't do this for the case where B0 is requested ("hang
> @@ -515,8 +515,6 @@ uart_get_baud_rate(struct uart_port *port, struct ktermios *termios,
>  							max - 1, max - 1);
>  		}
>  	}
> -	/* Should never happen */
> -	WARN_ON(1);
>  	return 0;
>  }
>  EXPORT_SYMBOL(uart_get_baud_rate);

While looking into this, I found this old commit:

commit 16ae2a877bf4179737921235e85ceffd7b79354f
Author: Alan Cox <alan@linux.intel.com>
Date:   Mon Jan 4 16:26:21 2010 +0000

    serial: Fix crash if the minimum rate of the device is > 9600 baud
    
    In that situation if the old rate is invalid and the new rate is invalid
    and the chip cannot do 9600 baud we report zero, which makes all the
    drivers explode.
    
    Instead force the rate based on min/max

But for some reason it does not work as advertized here? What is the exact 
cause for that?

Is something wrong with how min/max have that +1/-1 there or what?

-- 
 i.


  reply	other threads:[~2023-09-29  6:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28 15:16 [PATCH v4 0/5] serial: add drivers for the ESP32xx serial devices Max Filippov
2023-09-28 15:16 ` [PATCH v4 1/5] serial: core: tidy invalid baudrate handling in uart_get_baud_rate Max Filippov
2023-09-29  6:34   ` Ilpo Järvinen [this message]
2023-09-29 19:26     ` Max Filippov
2023-10-03 12:39   ` Greg Kroah-Hartman
2023-09-28 15:16 ` [PATCH v4 2/5] dt-bindings: serial: document esp32-uart Max Filippov
2023-09-28 15:16 ` [PATCH v4 3/5] drivers/tty/serial: add driver for the ESP32 UART Max Filippov
2023-10-03 12:56   ` Greg Kroah-Hartman
2023-09-28 15:16 ` [PATCH v4 4/5] dt-bindings: serial: document esp32s3-acm Max Filippov
2023-09-28 15:16 ` [PATCH v4 5/5] drivers/tty/serial: add ESP32S3 ACM device driver Max Filippov
2023-10-03 12:55   ` Greg Kroah-Hartman
2023-10-03 19:46     ` Max Filippov
2023-10-05 18:57       ` Greg Kroah-Hartman
2023-10-05 21:21         ` Max Filippov
2023-10-06  9:34           ` Greg Kroah-Hartman
2023-10-06 10:27             ` Max Filippov
2023-10-06 11:04               ` Greg Kroah-Hartman
2023-10-06 14:11       ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=69902af8-103-38a8-c438-87f7a047497@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jcmvbkbc@gmail.com \
    --cc=jirislaby@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).