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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Oct 2016 17:51:07 +0200
From:   Richard Genoud <richard.genoud@...il.com>
To:     Alexandre Belloni <alexandre.belloni@...e-electrons.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

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.