linux-kernel - Re: [PATCH 2/2] serial: atmel: don't stop the transmitter when doing PIO

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]

Message-ID: <df233ce37626fdb194b583808326d966@walle.cc>
Date:   Wed, 23 Nov 2022 09:50:20 +0100
From:   Michael Walle <michael@...le.cc>
To:     "Jiri Slaby (SUSE)" <jirislaby@...nel.org>
Cc:     gregkh@...uxfoundation.org, linux-serial@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Richard Genoud <richard.genoud@...il.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/2] serial: atmel: don't stop the transmitter when doing
 PIO

Am 2022-11-23 09:27, schrieb Jiri Slaby (SUSE):
> Writing ATMEL_US_TXDIS to ATMEL_US_CR makes the transmitter NOT to send
> the just queued character. This means when the character is last and
> uart calls ops->stop_tx(), the character is not sent at all.
> 
> The usart datasheet is not much specific on this, it just says the
> transmitter is stopped. But apparently, the character is dropped. So
> we should stop the transmitter only for DMA and PDC transfers to not
> send any more characters. For PIO, this is unexpected and deviates from
> other drivers. In particular, the below referenced commit broke TX as 
> it
> added a call to ->stop_tx() after the very last character written to 
> the
> transmitter.
> 
> So fix this by limiting the write of ATMEL_US_TXDIS to DMA transfers
> only.
> 
> Even there, I don't know if it is correctly implemented. Are all the
> queued characters sent once ->start_tx() is called? Anyone tested flow
> control -- be it hard (RTSCTS) or the soft (XOFF/XON) one?
> 
> Fixes: 2d141e683e9a ("tty: serial: use uart_port_tx() helper")
> Cc: Richard Genoud <richard.genoud@...il.com>
> Cc: Nicolas Ferre <nicolas.ferre@...rochip.com>
> Cc: Alexandre Belloni <alexandre.belloni@...tlin.com>
> Cc: Claudiu Beznea <claudiu.beznea@...rochip.com>
> Cc: linux-arm-kernel@...ts.infradead.org
> Reported-by: Michael Walle <michael@...le.cc>
> Signed-off-by: Jiri Slaby (SUSE) <jirislaby@...nel.org>

Already merged, but:
Tested-by: Michael Walle <michael@...le.cc>

Thanks,
-michael