Drop the unnecessary WARN() in case the TTY buffers are ever full in
favour of a rate limited dev_err() which doesn't kill the machine when
panic_on_warn is set.

Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
---
 drivers/tty/serial/qcom_geni_serial.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index 5b6c5388efee..8bc4b240bf59 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -570,9 +570,8 @@ static void handle_rx_uart(struct uart_port *uport, u32 bytes, bool drop)
 
 	ret = tty_insert_flip_string(tport, port->rx_buf, bytes);
 	if (ret != bytes) {
-		dev_err(uport->dev, "%s:Unable to push data ret %d_bytes %d\n",
-				__func__, ret, bytes);
-		WARN_ON_ONCE(1);
+		dev_err_ratelimited(uport->dev, "failed to push data (%d < %u)\n",
+				ret, bytes);
 	}
 	uport->icount.rx += ret;
 	tty_flip_buffer_push(tport);
-- 
2.45.2

Hi,

On Tue, Oct 1, 2024 at 5:51 AM Johan Hovold <johan+linaro@kernel.org> wrote:
>
> Drop the unnecessary WARN() in case the TTY buffers are ever full in
> favour of a rate limited dev_err() which doesn't kill the machine when
> panic_on_warn is set.
>
> Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
> ---
>  drivers/tty/serial/qcom_geni_serial.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
> index 5b6c5388efee..8bc4b240bf59 100644
> --- a/drivers/tty/serial/qcom_geni_serial.c
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -570,9 +570,8 @@ static void handle_rx_uart(struct uart_port *uport, u32 bytes, bool drop)
>
>         ret = tty_insert_flip_string(tport, port->rx_buf, bytes);
>         if (ret != bytes) {
> -               dev_err(uport->dev, "%s:Unable to push data ret %d_bytes %d\n",
> -                               __func__, ret, bytes);
> -               WARN_ON_ONCE(1);
> +               dev_err_ratelimited(uport->dev, "failed to push data (%d < %u)\n",
> +                               ret, bytes);

Not that it really matters, but since you're fixing the type of
"bytes" to %u you probably should fix "ret" to %u too, which means
changing the type of it? Officially tty_insert_flip_string returns the
(unsigned) size_t.

As a nit, I'd also say that your error message shouldn't assert "<"
unless you change your "if" test to "<". It seems safer to use != so
IMO the printout should also say "!=".

I'd hope you're not hitting this error a lot because it means you're
dropping bytes, but getting rid of the WARN_ON and changing to
ratelimited makes sense to me.

Reviewed-by: Douglas Anderson <dianders@chromium.org>

On Thu, Oct 03, 2024 at 01:06:43PM -0700, Doug Anderson wrote:
> On Tue, Oct 1, 2024 at 5:51 AM Johan Hovold <johan+linaro@kernel.org> wrote:

> > @@ -570,9 +570,8 @@ static void handle_rx_uart(struct uart_port *uport, u32 bytes, bool drop)
> >
> >         ret = tty_insert_flip_string(tport, port->rx_buf, bytes);
> >         if (ret != bytes) {
> > -               dev_err(uport->dev, "%s:Unable to push data ret %d_bytes %d\n",
> > -                               __func__, ret, bytes);
> > -               WARN_ON_ONCE(1);
> > +               dev_err_ratelimited(uport->dev, "failed to push data (%d < %u)\n",
> > +                               ret, bytes);
> 
> Not that it really matters, but since you're fixing the type of
> "bytes" to %u you probably should fix "ret" to %u too, which means
> changing the type of it? Officially tty_insert_flip_string returns the
> (unsigned) size_t.

Yeah, that was changed recently, but apparently not all callers were
updated. I'll just leave this as is for now too.
 
> As a nit, I'd also say that your error message shouldn't assert "<"
> unless you change your "if" test to "<". It seems safer to use != so
> IMO the printout should also say "!=".

Possibly, but if we ever hit that we have bigger problems.

> I'd hope you're not hitting this error a lot because it means you're
> dropping bytes, but getting rid of the WARN_ON and changing to
> ratelimited makes sense to me.

No, this was just something I noticed when reviewing the function.

Johan