linux-kernel - Re: [PATCH] serial: imx: leave IRTS disabled if using modem-control CTS

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:   Thu, 17 Feb 2022 08:22:07 -0800
From:   Tim Harvey <tharvey@...eworks.com>
To:     Tomasz Moń <tomasz.mon@...lingroup.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        linux-serial@...r.kernel.org,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>,
        Richard Genoud <richard.genoud@...il.com>,
        Sergey Organov <sorganov@...il.com>
Subject: Re: [PATCH] serial: imx: leave IRTS disabled if using modem-control CTS

On Tue, Feb 15, 2022 at 9:45 PM Tomasz Moń <tomasz.mon@...lingroup.com> wrote:
>
> On 15.02.2022 18:26, Tim Harvey wrote:
> > On Mon, Feb 14, 2022 at 10:03 PM Tomasz Moń <tomasz.mon@...lingroup.com> wrote:
> >> This hardware flow control sounds quite limited. Once CTS becomes
> >> inactive, the transmitter will still output all characters from TxFIFO.
> >> Transmitting whole TxFIFO already sounds quite bad, but that's the best
> >> case scenario where gpio interrupt is handled right away without any
> >> delay (so more than TxFIFO characters can actually be transmitted).
> >>
> >> Does the internal RTS default to inactive when it's not pinmuxed to the
> >> actual pin? If so, then controlling UCR2_IRTS based on CTS gpio could
> >> halt the transmission when the TxFIFO is not empty.
> >>> I agree that the increased latency makes using a GPIO for CTS
> > (software controlled) not as good as one pinmuxed into the UART block
> > directly (hardware controlled) but without this patch GPIO for CTS
> > does not work at all because the internal RTS defaults to inactive
> > when its not pinmuxed. For many applications the latency is not an
> > issue.
>
> I think I didn't write the message clear enough. I agree, that the GPIO
> handling time is something the user has to accept. Usually this part
> alone is not that bad though, as many receivers are capable of receiving
> more than one character after deasserting their RTS output (transmitter
> CTS input).
>
> The general expectation is that the transmitter will output maximum one
> more character *after* CTS GPIO change is handled by software. This is
> not the case with current version of the patch.
>
> With current version of the patch, after CTS GPIO handler finishes, the
> UART will continue to transmit up to 32 characters if not using DMA.
> When DMA is active it is much worse, as it will keep transmitting all
> data already submitted to dmaengine.
>
> As the internal RTS defaults to inactive when its not pinmuxed, the
> software is able to freeze the TxFIFO (and thus DMA if enabled). To
> freeze TxFIFO when using CTS GPIO, the software has to clear IRTS bit in
> UCR2 register. Setting IRTS will thaw the TxFIFO.
>

Tomasz,

Ok - I understand what you are saying. Yes, I should be able to use
IRTS to freeze/thaw the transmitter based on it being inactive when
not pinmuxed. I will work on a v2.

Thanks for the explanation!

Best Regards,

Tim