Re: [PATCH] serial: fsl_lpuart: add support for GPIO-controlled modem lines

Re: [PATCH] serial: fsl_lpuart: add support for GPIO-controlled modem lines

[Greg Kroah-Hartman]

On Wed, Aug 19, 2026 at 04:44:53PM +0200, João Loureiro wrote:
> LPUART has no register bit to drive RTS to a chosen level: UARTMODIR only
> offers receiver-driven auto-RTS (RXRTSE) and RTS-during-transmit (TXRTSE).
> Consequently lpuart_set_mctrl() and lpuart32_set_mctrl() ignore TIOCM_RTS,
> and their get_mctrl() counterparts report a hardcoded
> TIOCM_CAR | TIOCM_DSR | TIOCM_CTS.
> 
> That makes it impossible to talk to a peripheral which is driven by a
> software controlled RTS strobe and answers on CTS.  TIOCMBIS/TIOCMBIC
> silently do nothing, and because CTS always reads back as asserted, a
> userspace handshake that waits for CTS to follow RTS can never complete:
> de-asserting RTS and waiting for CTS to drop times out every time.  Boards
> that route the two pins to plain GPIOs cannot work around it either, since
> the driver never looks at rts-gpios/cts-gpios.
> 
> Wire the driver up to the serial_mctrl_gpio helpers, as imx.c and
> atmel_serial.c already do.  set_mctrl() forwards the state to
> mctrl_gpio_set(), and get_mctrl() runs the flags through mctrl_gpio_get()
> so that a described cts-gpios overrides the assumed-asserted default.
> Boards without such a description keep the previous behaviour.  Modem
> status interrupts are enabled from startup() and disabled from shutdown(),
> with a .enable_ms callback for the serial core.
> 
> The same limitation was reported for an i.MX 8XLite board that needs RS-485
> with a GPIO RTS [1].  This change was developed and tested on an i.MX95
> board whose barcode scanner is driven over LPUART with a manual RTS strobe;
> with it, RTS toggles as requested and CTS is reported from the real pin.
> 
> [1] https://lore.kernel.org/all/20260210-rearview-hungrily-536a95fc3385@thorsis.com/
> 
> Signed-off-by: João Loureiro <joaofl@gmail.com>
> ---
>  drivers/tty/serial/Kconfig      |  1 +
>  drivers/tty/serial/fsl_lpuart.c | 35 +++++++++++++++++++++++++++++++--
>  2 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 4f57833e3ec7..a173eaf769ff 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1301,6 +1301,7 @@ config SERIAL_FSL_LPUART
>  	tristate "Freescale lpuart serial port support"
>  	depends on HAS_DMA
>  	select SERIAL_CORE
> +	select SERIAL_MCTRL_GPIO if GPIOLIB

Why not depends?

thanks,

greg k-h

Re: [PATCH] serial: fsl_lpuart: add support for GPIO-controlled modem lines

[João Loureiro]

On Wed, Sep 23, 2026 at 02:53PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 19, 2026 at 04:44:53PM +0200, João Loureiro wrote:
> > --- a/drivers/tty/serial/Kconfig
> > +++ b/drivers/tty/serial/Kconfig
> > @@ -1301,6 +1301,7 @@ config SERIAL_FSL_LPUART
> >       tristate "Freescale lpuart serial port support"
> >       depends on HAS_DMA
> >       select SERIAL_CORE
> > +     select SERIAL_MCTRL_GPIO if GPIOLIB
>
> Why not depends?

Because SERIAL_MCTRL_GPIO is a hidden symbol.  It is declared as a bare
"tristate" with no prompt at the end of the same Kconfig file, so it can
only ever be enabled by a select.  With "depends on SERIAL_MCTRL_GPIO"
nothing could ever satisfy the dependency and SERIAL_FSL_LPUART would
become unselectable.

The dependency is also not a hard one.  serial_mctrl_gpio.h provides
no-op static inlines for the !CONFIG_GPIOLIB case, so fsl_lpuart still
builds and behaves exactly as before when GPIOLIB is off; the GPIO modem
lines are an optional extra rather than a requirement.  A depends would
silently drop LPUART from those configurations.

Finally, this is what every other user of the helpers does:
SERIAL_ATMEL, SERIAL_IMX, SERIAL_SH_SCI, SERIAL_STM32, SERIAL_MXS_AUART,
SERIAL_SA1100, SERIAL_CLPS711X and SERIAL_AR933X all spell it as
"select SERIAL_MCTRL_GPIO if GPIOLIB" in the same file, so this keeps
fsl_lpuart consistent with them.

Thanks,
João