linux-kernel - Re: [PATCH] serial: imx: also enable Transmit Complete interrupt in rs232 mode

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: <1e9ac484-5764-496d-ab00-9690d9042c91@gmx.de>
Date:   Wed, 22 Nov 2023 10:31:53 +0100
From:   Eberhard Stoll <eberhard.stoll@....de>
To:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>, sherry.sun@....com
Cc:     festevam@...il.com, gregkh@...uxfoundation.org,
        jirislaby@...nel.org, kernel@...gutronix.de,
        linux-arm-kernel@...ts.infradead.org, linux-imx@....com,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        s.hauer@...gutronix.de, shawnguo@...nel.org,
        eberhard.stoll@...tron.de
Subject: Re: [PATCH] serial: imx: also enable Transmit Complete interrupt in
 rs232 mode


>> i can observe a very similar situation, but with a litte different
>> configuration. This is how i can trigger the situation very quickly:
>>
>>    1) open the port
>>    2) send 1 byte out
>>    3) close the port
>
> Hi Eberhard
>
> Thanks for chiming in. I assume this is all in rs485 mode, no switching
> to rs232 and back involved?

Yes, no mode switching is involved here. Only rs485 mode.

>> Setting ->tx_state = SEND in imx_uart_shutdown() helps for my issue
>> (and should be ok IMHO).
>
> [I assume you mean tx_state = OFF]. Yes, I suppose doing that would be > ok, but I'm not sure it's a complete fix. In my simple test cast, I have

Oh, yes, sorry my mistake!
I really meant ->tx_state = OFF as you expected in your comment

> separate programs invoked to do the I/O and do the mode switch, but in a
> real scenario, I'd expect the application itself to just open the device
> once, and then do I/O and mode switching as appropriate for the
> application logic, and I don't think uart_shutdown would then ever get
> called.

Switching between rs232 mode and rs485 mode on an open port is a special
use case in my experience. But it's valid and introduces some extra
complexity. As you stated, for this use case setting ->tx_state = OFF in
imx_uart_shutdown() does not really help.

> Indeed, that's an extra complication. Adding two hrtimer_try_to_cancel()
> in shutdown would probably not hurt, along with setting tx_state OFF.
>
> I wonder if at least mode switching should simply be disallowed (-EBUSY)
> if tx_state is anything but OFF.

Seems there are various issues in ->tx_state handling and transmitter
timing in this driver!

Best Regards
Eberhard