rts-gpios support in fsl_lpuart driver?

rts-gpios support in fsl_lpuart driver?

[Alexander Dahl]

Hello everyone,

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

Re: rts-gpios support in fsl_lpuart driver?

[Frank Li]

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
>

Re: rts-gpios support in fsl_lpuart driver?

[Manikanta guntupalli]

Hi Alex,

On Tue, 10 Feb 2026, 21:28 Frank Li, <Frank.li@nxp.com> wrote:
>
> 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
> >
>
If we are using gpio as rts line, we need to handle it in the driver sequence.
Please refer to the patch below, that may be helpful.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.19&id=fccc9d9233f918ee50cf2955ae7134a7f3418351

Thanks,
Manikanta.

RE: rts-gpios support in fsl_lpuart driver?

[Sherry Sun]

> 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.

Yes, currently the lpuart driver only supports auto RS-485 RTS mode.
We haven't received any requests for sw-controlled RTS mode (rts-gpio).
We can consider adding this feature in the future if such requests arise.

Best Regards
Sherry
> 
> 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
> >