linux-kernel - Re: rts-gpios support in fsl

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: <aYtVNxZU4tqtj2fo@lizhi-Precision-Tower-5810>
Date: Tue, 10 Feb 2026 10:56:39 -0500
From: Frank Li <Frank.li@....com>
To: imx@...ts.linux.dev, linux-serial@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Roelf-Erik Carsjens <rca@...rsis.com>,
	Josua Mayer <josua@...id-run.com>, sherry.sun@....com
Subject: Re: rts-gpios support in fsl_lpuart driver?

On Tue, Feb 10, 2026 at 12:48:05PM +0100, Alexander Dahl wrote:
> Hello everyone,

Add sherry. look like we have not implemented it at lpuart.

Frank
>
> we are currently experimenting with the SolidRun 8XLite SoM featuring
> an i.MX 8XLite SoC on a custom base board.  Due to how our peripheral
> hardware is connected we need to use rs485 with uart3, which has no
> native soc controlled rts line.  On different SoCs you just use
> 'rts-gpios' in devicetree then, letting the kernel switch this line
> through gpio.  Alas it does not work on this SoC, the RTS line is not
> switched at all. :-/
>
> According to my analysis the i.MX8 family has different variants using
> different uarts with different drivers.  For the variants using the
> imx.c driver, you find dts files using rts-gpios, but for variants
> using the fsl_lpuart.c driver you find none.
>
> The rts-gpios property is evaluated by the serial core in
> `mctrl_gpio_init()` right?  And the actual switching is also done
> through that mctrl_gpio interface, right?  As far as I understand the
> source code, the serial core calls the .set_mctrl function pointer,
> and then it is up to the driver what to do?  Some (like atmel_serial.c
> and imx.c) call mctrl_gpio_set() in the function mapped to that
> pointer, some (like fsl_lpuart.c) don't.  Correct so far?
>
> Up to this point I'm somewhat confused this is no generic feature in
> the core which works for any uart, but there's probably a reason for
> that?  Maybe interaction with the actual uart registers in some way?
>
> If it is like described, I'd say the fsl_lpuart driver currently just
> does not support this usecase?  Is it possible to implement the
> necessary things?  Is anybody already working on that?  I looked in my
> mailing list archive and in the imx downstream kernel, but could not
> find any hints.
>
> Any advice welcome. :-)
>
> Greets
> Alex
>