On Fri, Aug 05, 2022 at 11:20:24AM +0000, Roosen Henri wrote:
> On Fri, 2022-08-05 at 10:18 +0200, Lukas Wunner wrote:
> > On Thu, Aug 04, 2022 at 04:11:26PM +0000, Roosen Henri wrote:
> > > On Thu, 2022-08-04 at 17:52 +0200, Lukas Wunner wrote:
> > > > On Thu, Aug 04, 2022 at 02:38:23PM +0000, Roosen Henri wrote:
> > > > > unfortunately this commit, which has been backported to v5.4.x,
> > > > > seems
> > > > > to break RS485 functionality on our iMX boards.
Thanks for the report and sorry for the breakage.
I see what the problem is. The serial core assumes that RTS in mctrl
has inverted semantics and that doesn't hold for mctrl_gpio.
I guess the takeaway is that deasserting RS485 Transmit Enable is
really driver-specific. In particular, imx.c has support for using
CTS to drive Transmit Enable and the serial core can't deassert that
on probe because it doesn't know about this driver-specific feature.
In the case of imx.c, the driver already deasserts Transmit Enable via:
imx_uart_probe()
uart_rs485_config()
imx_uart_rs485_config()
(Those function names refer to current mainline, uart_rs485_config()
will be newly introduced in v6.0.)
Thus, just deleting deassertion from uart_configure_port() should fix
the issue for imx.c:
- if (port->rs485.flags & SER_RS485_ENABLED &&
- !(port->rs485.flags & SER_RS485_RTS_AFTER_SEND))
- port->mctrl |= TIOCM_RTS;
I need to go through all other rs485-capable drivers to check whether
the same is true for them or which ones need to be amended. Please
stand by.
Thanks,
Lukas
