linux-kernel - Re: [PATCH] tty/serial: at91: fix hardware handshake on Atmel platforms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 26 Oct 2016 18:09:03 +0200
From:   Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:     Richard Genoud <richard.genoud@...il.com>
Cc:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Nicolas Ferre <nicolas.ferre@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Cyrille Pitchen <cyrille.pitchen@...el.com>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] tty/serial: at91: fix hardware handshake on Atmel
 platforms

On 26/10/2016 at 17:51:07 +0200, Richard Genoud wrote :
> 2016-10-26 17:35 GMT+02:00 Alexandre Belloni
> <alexandre.belloni@...e-electrons.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
> > :)
> 
> So you broke this on purpose ?
> Without saying so in the commit message ?
> Nice to know.

No, I didn't think about that use case at the time and I understood
after you explanations. I wouldn't have removed an existing
functionality like that.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com