Linux Serial subsystem development
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Michael Pratt <mcpratt@pm.me>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	 LKML <linux-kernel@vger.kernel.org>,
	 linux-serial <linux-serial@vger.kernel.org>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 Jiri Slaby <jirislaby@kernel.org>,
	 Wander Lairson Costa <wander@redhat.com>,
	 Vamshi Gajjela <vamshigajjela@google.com>
Subject: Re: [PATCH v2 3/3] serial: 8250: Set fifo timeout using uart_fifo_timeout()
Date: Wed, 17 Apr 2024 11:13:21 +0300 (EEST)	[thread overview]
Message-ID: <7e66eafe-902c-38ab-b624-d9386c1bcd22@linux.intel.com> (raw)
In-Reply-To: <CmMdmgjPFh8R-rH0-mjU0QdQcqhRwVr9bmApDJ7BV_9DjRBL35K_Qfjs7oIPVwGFv5mdT476a8tPtkgnWqY2lRBEfGvfhjk0yW9ueI4bcf8=@pm.me>

On Tue, 16 Apr 2024, Michael Pratt wrote:
> On Tuesday, April 16th, 2024 at 14:57, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> > > unsigned int status, tmout = 10000;
> > > 
> > > - /* Wait up to 10ms for the character(s) to be sent. /
> > > + / Wait for a time relative to buffer size and baud */
> > > + if (up->fifo_enable && up->port.timeout)
> > > + tmout = jiffies_to_usecs(up->port.timeout);
> > 
> > 
> > Why do we still use that default? Can't we calculate timeout even for\
> > FIFO-less / FIFO-disabled devices?

Yes we definitely should be able to. Unfortunately these patches just keep 
coming back not in the form that follows the review feedback, but they 
come up their own way of doing things which is way worse and ignores the 
given feedback.

> Maybe it's possible that there is some kind of rare case where the LSR register
> is not working or not configured properly for a device in which support
> is being worked on...without a timeout, that would result in an infinite loop.

"without a timeout" is not what Andy said. He said you should always have 
a timeout, regardless of there being FIFO or not. And that timeout should 
be derived in the same manner from baudrate and FIFO size (to address the
cases w/o FIFO, the fifosize should be lower bounded to 1 while 
calculating the FIFO timeout).

> AFAIK, when everything is working properly, there is no such thing as needing
> a timeout for a uart device without fifo, as every single byte written would trigger
> an interrupt anyway.

While I agree the general principle, that this is backup that should not 
even be needed, the statement is partly incorrect. We don't get interrupts 
during console write because they're disabled. But LSR should still change 
and allow progress without the backup timeout.

-- 
 i.


  reply	other threads:[~2024-04-17  8:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16 18:28 [PATCH v2 0/3] serial: 8250: Set fifo timeout with uart_fifo_timeout() Michael Pratt
2024-04-16 18:29 ` [PATCH v2 1/3] serial: core: Store fifo timeout again Michael Pratt
2024-04-16 18:58   ` Andy Shevchenko
2024-04-16 19:20     ` Michael Pratt
2024-04-17  8:18       ` Ilpo Järvinen
2024-04-17 15:41       ` Wander Lairson Costa
2024-04-17  7:52   ` Ilpo Järvinen
2024-04-16 18:29 ` [PATCH v2 2/3] serial: 8250: Store whether fifo device is enabled Michael Pratt
2024-04-16 18:55   ` Andy Shevchenko
2024-04-16 19:09     ` Michael Pratt
2024-04-16 19:18       ` Andy Shevchenko
2024-04-16 19:40         ` Michael Pratt
2024-04-16 18:34 ` [PATCH v2 3/3] serial: 8250: Set fifo timeout using uart_fifo_timeout() Michael Pratt
2024-04-16 18:57   ` Andy Shevchenko
2024-04-16 19:15     ` Michael Pratt
2024-04-17  8:13       ` Ilpo Järvinen [this message]
2024-04-17  8:00   ` Ilpo Järvinen

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=7e66eafe-902c-38ab-b624-d9386c1bcd22@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mcpratt@pm.me \
    --cc=vamshigajjela@google.com \
    --cc=wander@redhat.com \
    /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