From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Richard Genoud <richard.genoud@gmail.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Nicolas Ferre" <nicolas.ferre@atmel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Cyrille Pitchen" <cyrille.pitchen@atmel.com>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] tty/serial: at91: fix hardware handshake on Atmel platforms
Date: Wed, 26 Oct 2016 17:35:48 +0200 [thread overview]
Message-ID: <20161026153548.xxvciigcscrjb5uv@piout.net> (raw)
In-Reply-To: <f89c29e4-b68f-a8ea-cefb-e70dda6739a0@gmail.com>
Richard,
On 26/10/2016 at 16:55:02 +0200, Richard Genoud wrote :
> On 25/10/2016 19:17, Uwe Kleine-König wrote:
> Quote from the commit message:
> " Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
> hardware handshake is enabled") actually allowed to enable hardware
> handshaking.
> Before, the CRTSCTS flags was silently ignored.
> "
> This wasn't true.
> This was a misunderstanding of the ATMEL_US_USMODE_HWHS flag:
> Commit 1cf6e8fc8341 didn't allowed to enable hardware handshaking, but
> introduced the ATMEL_US_USMODE_HWHS flag.
> And before 1cf6e8fc8341, the CRTSCTS flags wasn't silently ignored, it
> was perfectly respected.
>
It was not really a misunderstanding, it is a difference in
expectations. There is one topic on which we don't agree and I'm fine
with your solution as long as I don't have to support people with the
failures (hence my ack). My (and Cyrille's) opinion is that CRTSCTS has
to be 100% reliable and this is only possible with assistance from the
hardware. That's why I wanted to report when HW didn't have proper
support to userspace.
On your side you are fine with software handling of RTS and CTS (which
is a feature that worked before our patches). You just have to remember
that at some point because of latencies and the way the IPs are clocked,
this will fail and you'll start losing bytes.
Again, I'm fine with that but I won't handle people complaining about it
:)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-10-26 15:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-25 16:11 [PATCH] tty/serial: at91: fix hardware handshake on Atmel platforms Richard Genoud
2016-10-25 16:22 ` Alexandre Belloni
2016-10-26 6:52 ` Richard Genoud
2016-10-25 17:17 ` Uwe Kleine-König
2016-10-26 14:55 ` Richard Genoud
2016-10-26 15:35 ` Alexandre Belloni [this message]
2016-10-26 15:51 ` Richard Genoud
2016-10-26 16:09 ` Alexandre Belloni
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=20161026153548.xxvciigcscrjb5uv@piout.net \
--to=alexandre.belloni@free-electrons.com \
--cc=cyrille.pitchen@atmel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=nicolas.ferre@atmel.com \
--cc=richard.genoud@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/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).