On Fri, 6 Sep 2024, Jiri Slaby wrote:
> It seems gmail refuses to send this to zaq14760@xxxxxxxxx (the author).
>
> On 06. 09. 24, 4:19, LiangCheng Wang wrote:
> > The rs485.flags are lost in functions such as imx_uart_stop_tx(),
> > causing the function of RS485 to be invalid when using the
> > serial port as the RS485 port. Use a variable to store the state to
> > avoid this issue.
>
> AFAICT, this feels rather wrong. Any rs485 experts around?
It is wrong. The patch makes no sense at all and prevents
reconfiguring/setting rs485 from userspace.
> At minimum, how are the flags "lost" and why this does not matter to other
> drivers?
Perhaps some userspace program is altering rs485 settings, definitely
nothing in imx_uart_stop_tx() writes to it. I'm skeptical it would be a
problem in the kernel, especially given the patch that is supposed to
"avoid the issue" (whatever the issue is).
> > --- a/drivers/tty/serial/imx.c
> > +++ b/drivers/tty/serial/imx.c
> > @@ -209,7 +209,7 @@ struct imx_port {
> > const struct imx_uart_data *devdata;
> > struct mctrl_gpios *gpios;
> > -
> > + int flags;
>
> Definitely not int for flags.
Driver is not supposed to duplicate the rs485 flags at all.
--
i.
