All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	linux-serial@vger.kernel.org,
	"Greg KH" <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	"Gilles Buloz" <gilles.buloz@kontron.com>,
	"Johan Hovold" <johan@kernel.org>
Subject: Re: [PATCH 2/2] tty: Implement lookahead to process XON/XOFF timely
Date: Wed, 6 Apr 2022 11:54:05 +0300	[thread overview]
Message-ID: <Yk1VLWMmMu6jJEWo@smile.fi.intel.com> (raw)
In-Reply-To: <fce9c28e-a334-3c70-3a6a-8812f11d8fc7@kernel.org>

On Wed, Apr 06, 2022 at 10:21:12AM +0200, Jiri Slaby wrote:
> On 05. 04. 22, 18:11, Andy Shevchenko wrote:
> > On Tue, Apr 05, 2022 at 01:24:37PM +0300, Ilpo Järvinen wrote:
> > > When tty is not read from, XON/XOFF may get stuck into an
> > > intermediate buffer. As those characters are there to do software
> > > flow-control, it is not very useful. In the case where neither end
> > > reads from ttys, the receiving ends might not be able receive the
> > > XOFF characters and just keep sending more data to the opposite
> > > direction. This problem is almost guaranteed to occur with DMA
> > > which sends data in large chunks.
> > > 
> > > If TTY is slow to process characters, that is, eats less than given
> > > amount in receive_buf, invoke lookahead for the rest of the chars
> > > to process potential XON/XOFF characters.
> > > 
> > > The guards necessary for ensuring the XON/XOFF character are
> > > processed only once were added by the previous patch. All this patch
> > > needs to do on that front is to pass the lookahead count (that can
> > > now be non-zero) into port->client_ops->receive_buf().
> > 
> > ...
> > 
> > > +static bool __n_tty_receive_char_special(struct tty_struct *tty, unsigned char c,
> > > +					 bool lookahead_done)
> > > +{
> > > +	if (!I_IXON(tty))
> > > +		return false;
> > > +
> > > +	if (c == START_CHAR(tty)) {
> > > +		if (!lookahead_done) {
> > > +			start_tty(tty);
> > > +			process_echoes(tty);
> > > +		}
> > > +		return true;
> > > +	}
> > > +	if (c == STOP_CHAR(tty)) {
> > > +		if (!lookahead_done)
> > > +			stop_tty(tty);
> > > +		return true;
> > > +	}
> > > +	return false;
> > > +}
> > 
> > Looking into this I would first make a preparatory patch that splits out
> > current code into something like
> > 
> > static bool __n_tty_receive_char_special_no_lookahead(struct tty_struct *tty, unsigned char c)
> > {
> > 	...current code...
> > }
> > 
> > Then in the patch 1 you add
> > 
> > static bool __n_tty_receive_char_special_lookahead(struct tty_struct *tty, unsigned char c)
> > {
> > 	...
> > }
> > 
> > static bool __n_tty_receive_char_special(struct tty_struct *tty, unsigned char c,
> > 					 bool lookahead_done)
> 
> This should be dubbed better. Maybe n_tty_receive_char_flow_control()?
> 
> And I would place the if (I_IXON(tty)) to the caller. I am a bit lost in
> this pseudo code, so maybe this doesn't make sense in your proposal. I have
> something like in my mind:
> 
> if (I_IXON(tty))
>   return n_tty_receive_char_flow_control();

My point to have three helpers which make each change cleaner:

  .-> n_tty_receive_char_flow_control_lah()
  |
  |  .-> n_tty_receive_char_flow_control_no_lah()
  |  |
  `- + -- n_tty_receive_char_flow_control()

Where no_lah variant can be split as preparatory patch prepending the current
series.

And yes, calling I_IXON at the caller seems better.

> Historically, these n_tty_receive* function names were a big mess. Don't
> produce more of that by simply prepending only "__".
> 
> > {
> > 	if (!I_IXON(tty))
> > 		return false;
> > 
> > 	if (lookahead_done)
> > 		return _lookahead();
> > 
> > 	return _no_lookahead();
> > }

-- 
With Best Regards,
Andy Shevchenko



  parent reply	other threads:[~2022-04-06 12:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05 10:24 [PATCH 0/2] tty/serial: Process XON/XOFF robustly Ilpo Järvinen
2022-04-05 10:24 ` [PATCH 1/2] tty: Add lookahead param to receive_buf Ilpo Järvinen
2022-04-05 16:03   ` Andy Shevchenko
2022-04-06  8:07     ` Jiri Slaby
2022-04-06  8:13   ` Jiri Slaby
2022-04-06  8:46     ` Ilpo Järvinen
2022-04-05 10:24 ` [PATCH 2/2] tty: Implement lookahead to process XON/XOFF timely Ilpo Järvinen
2022-04-05 16:11   ` Andy Shevchenko
2022-04-06  8:21     ` Jiri Slaby
2022-04-06  8:50       ` Ilpo Järvinen
2022-04-06  8:54       ` Andy Shevchenko [this message]
2022-04-06  8:56         ` Andy Shevchenko

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=Yk1VLWMmMu6jJEWo@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=gilles.buloz@kontron.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jirislaby@kernel.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.