All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Matthias Schiffer <matthias.schiffer@ew.tq-group.com>,
	Roosen Henri <Henri.Roosen@ginzinger.com>,
	linux-serial <linux-serial@vger.kernel.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	Lino Sanfilippo <LinoSanfilippo@gmx.de>,
	David Laight <David.Laight@ACULAB.COM>,
	Maarten Brock <m.brock@vanmierlo.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Su Bao Cheng <baocheng.su@siemens.com>,
	baocheng_su@163.com, Chao Zeng <chao.zeng@siemens.com>,
	Peter Hung <hpeter+linux_kernel@gmail.com>,
	Joachim Eastwood <manabian@gmail.com>,
	Daniel Golle <daniel@makrotopia.org>,
	Codrin Ciubotariu <Codrin.Ciubotariu@microchip.com>,
	Sherry Sun <sherry.sun@nxp.com>,
	Serge Semin <Sergey.Semin@baikalelectronics.ru>,
	Ricardo Ribalda <ribalda@kernel.org>,
	Dario Binacchi <dariobin@libero.it>,
	Bich Hemon <bich.hemon@st.com>, Marek Vasut <marex@denx.de>
Subject: Re: [PATCH] serial: Deassert RS485 Transmit Enable on probe in driver-specific way
Date: Fri, 16 Sep 2022 15:27:58 +0300 (EEST)	[thread overview]
Message-ID: <94e754d-12ae-271c-9462-7f90ebb2b164@linux.intel.com> (raw)
In-Reply-To: <b17842d9792762948f75d74205596d36bdd27f22.1663310999.git.lukas@wunner.de>

On Fri, 16 Sep 2022, Lukas Wunner wrote:

> When a UART port is newly registered, uart_configure_port() seeks to
> deassert RS485 Transmit Enable by setting the RTS bit in port->mctrl.
> However a number of UART drivers interpret a set RTS bit as *assertion*
> instead of deassertion:  Affected drivers include those using
> serial8250_em485_config() (except 8250_bcm2835aux.c) and some using
> mctrl_gpio (e.g. imx.c).
> 
> Since the interpretation of the RTS bit is driver-specific, it is not
> suitable as a means to centrally deassert Transmit Enable in the serial
> core.  Instead, the serial core must call on drivers to deassert it in
> their driver-specific way.  One way to achieve that is to call
> ->rs485_config().  It implicitly deasserts Transmit Enable.
> 
> So amend uart_configure_port() and uart_resume_port() to invoke
> uart_rs485_config().  That allows removing calls to uart_rs485_config()
> from drivers' ->probe() hooks and declaring the function static.
> 
> Skip any invocation of ->set_mctrl() if RS485 is enabled.  RS485 has no
> hardware flow control, so the modem control lines are irrelevant and
> need not be touched.  When leaving RS485 mode, reset the modem control
> lines to the state stored in port->mctrl.  That way, UARTs which are
> muxed between RS485 and RS232 transceivers drive the lines correctly
> when switched to RS232.  (serial8250_do_startup() historically raises
> the OUT1 modem signal because otherwise interrupts are not signaled on
> ancient PC UARTs, but I believe that no longer applies to modern,
> RS485-capable UARTs and is thus safe to be skipped.)
> 
> imx.c modifies port->mctrl whenever Transmit Enable is asserted and
> deasserted.  Stop it from doing that so port->mctrl reflects the RS232
> line state.
> 
> 8250_omap.c deasserts Transmit Enable on ->runtime_resume() by calling
> ->set_mctrl().  Because that is now a no-op in RS485 mode, amend the
> function to call serial8250_em485_stop_tx().
> 
> fsl_lpuart.c retrieves and applies the RS485 device tree properties
> after registering the UART port.  Because applying now happens on
> registration in uart_configure_port(), move retrieval of the properties
> ahead of uart_add_one_port().
> 
> Fixes: d3b3404df318 ("serial: Fix incorrect rs485 polarity on uart open")
> Reported-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> Link: https://lore.kernel.org/all/20220329085050.311408-1-matthias.schiffer@ew.tq-group.com/
> Reported-by: Roosen Henri <Henri.Roosen@ginzinger.com>
> Link: https://lore.kernel.org/all/8f538a8903795f22f9acc94a9a31b03c9c4ccacb.camel@ginzinger.com/
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: stable@vger.kernel.org # v4.14+
> ---
>  Based on v6.0-rc3 + this dependency:
>  https://lore.kernel.org/linux-serial/72fb646c1b0b11c989850c55f52f9ff343d1b2fa.1662884345.git.lukas@wunner.de/

> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 907c5ff..a6f03b1 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -600,7 +600,7 @@ void serial8250_rpm_put(struct uart_8250_port *p)
>  static int serial8250_em485_init(struct uart_8250_port *p)
>  {
>  	if (p->em485)
> -		return 0;
> +		goto deassert_rts;
>  
>  	p->em485 = kmalloc(sizeof(struct uart_8250_em485), GFP_ATOMIC);
>  	if (!p->em485)
> @@ -616,6 +616,7 @@ static int serial8250_em485_init(struct uart_8250_port *p)
>  	p->em485->active_timer = NULL;
>  	p->em485->tx_stopped = true;
>  
> +deassert_rts:
>  	p->rs485_stop_tx(p);

	if (p->em485->tx_stopped)
		p->rs485_stop_tx(p);

?

Because if p->em485->tx_stopped is false and serial8250_em485_init() is 
called again (the comment above it says it is safe to do so), it would 
stop tx at wrong point.

-- 
 i.


  parent reply	other threads:[~2022-09-16 12:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <b17842d9792762948f75d74205596d36bdd27f22.1663310999.git.lukas@wunner.de>
2022-09-16 11:22 ` [PATCH] serial: Deassert RS485 Transmit Enable on probe in driver-specific way Matthias Schiffer
2022-09-16 12:27 ` Ilpo Järvinen [this message]
2022-09-17 14:25   ` Lukas Wunner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=94e754d-12ae-271c-9462-7f90ebb2b164@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=Codrin.Ciubotariu@microchip.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=Henri.Roosen@ginzinger.com \
    --cc=LinoSanfilippo@gmx.de \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=baocheng.su@siemens.com \
    --cc=baocheng_su@163.com \
    --cc=bich.hemon@st.com \
    --cc=chao.zeng@siemens.com \
    --cc=daniel@makrotopia.org \
    --cc=dariobin@libero.it \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpeter+linux_kernel@gmail.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=m.brock@vanmierlo.com \
    --cc=manabian@gmail.com \
    --cc=marex@denx.de \
    --cc=matthias.schiffer@ew.tq-group.com \
    --cc=ribalda@kernel.org \
    --cc=sherry.sun@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.