From: Su Bao Cheng <baocheng_su@163.com>
To: Lukas Wunner <lukas@wunner.de>, Su Bao Cheng <baocheng.su@siemens.com>
Cc: linux-serial@vger.kernel.org, gregkh@linuxfoundation.org,
jan.kiszka@siemens.com, chao.zeng@siemens.com
Subject: Re: [PATCH] Revert "serial: 8250: Don't touch RTS modem control while in rs485 mode"
Date: Fri, 12 Nov 2021 14:14:11 +0800 [thread overview]
Message-ID: <e1a9b9bf-45a4-6e71-09f4-1ae730284778@163.com> (raw)
In-Reply-To: <20211027113938.GA9373@wunner.de>
On 2021/10/27 下午7:39, Lukas Wunner wrote:
> On Wed, Oct 27, 2021 at 07:16:44PM +0800, Su Bao Cheng wrote:
>> This reverts commit f45709df7731ad36306a28a3e1af7309d55c35f5.
>>
>> The `serial8250_do_set_mctrl` not only used by userspace ioctl but
>> also the kernel itself.
>>
>> During tty_open, the uart_port_startup sets the MCR to 0, and then use
>> set_mctrl to restore the MCR, so at this time, the MCR read does not
>> reflect the desired value.
>
> I don't quite follow. Where is uart_port_startup() setting the MCR to 0?
> Are you referring to the call to uart_port_dtr_rts()? That function should
> set RTS correctly according to RS485 state, so I don't see where any
> breakage may occur.
>
> What is the user-visible issue that you seek to fix with the revert?
>
Sorry for the late response, the company exchange server does not work
for me at this moment, so I have to use the private email instead.
The issue is observed on omap8250 hardware (CPU: AM6548). the use case
is RS485 half-duplex (2 wire mode), in this mode the RTS pin is used to
control the direction and is software controller via the MCR[1]
register. The problem is that the RS485 transmitting is OK, but the
receiving is not working. Similar issue also exists for the RS422, i.e.
the 4-wire full-duplex mode of RS485, but this time the TX does not
work, RX is fine.
The MCR is set to 0 at this line within uart_port_startup():
retval = uport->ops->startup(uport);
On omap8250, the startup() points to omap_8250_startup(), within it:
up->mcr = 0;
For software controlled RTS pin of RS485 half-duplex, when not in the
transmitting, the MCR[1] should be constant to indicate the current
direction is receiving. This is set in serial8250_em485_stop_tx().
So after this point of setting the MCR to 0, this up->mcr register
mirror does not reflect the actual desired value anymore. Further
checking against it leads to false result.
Another possible fix could be, instead of setting the mcr to 0 blindly,
one could check if the current operating mode is RS485 half-duplex, and
if so, mask the MCR[1], so that this bit is not changed. Because the
MCR[1] will be changed to the correct value before TX in
serial8250_em485_start_tx(), this change would not impact the transmitting.
> Thanks,
>
> Lukas
>
>> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
>> index 66374704747e..40736e460956 100644
>> --- a/drivers/tty/serial/8250/8250_port.c
>> +++ b/drivers/tty/serial/8250/8250_port.c
>> @@ -2024,13 +2024,6 @@ void serial8250_do_set_mctrl(struct uart_port *port, unsigned int mctrl)
>> struct uart_8250_port *up = up_to_u8250p(port);
>> unsigned char mcr;
>>
>> - if (port->rs485.flags & SER_RS485_ENABLED) {
>> - if (serial8250_in_MCR(up) & UART_MCR_RTS)
>> - mctrl |= TIOCM_RTS;
>> - else
>> - mctrl &= ~TIOCM_RTS;
>> - }
>> -
>> mcr = serial8250_TIOCM_to_MCR(mctrl);
>>
>> mcr = (mcr & up->mcr_mask) | up->mcr_force | up->mcr;
>> --
>> 2.25.1
next prev parent reply other threads:[~2021-11-12 6:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 11:16 [PATCH] Revert "serial: 8250: Don't touch RTS modem control while in rs485 mode" Su Bao Cheng
2021-10-27 11:39 ` Lukas Wunner
2021-11-12 6:14 ` Su Bao Cheng [this message]
2021-11-19 8:00 ` Jan Kiszka
2021-11-19 8:43 ` Jan Kiszka
2021-11-19 11:17 ` Lukas Wunner
2021-11-19 11:12 ` Lukas Wunner
2021-11-20 17:18 ` Lukas Wunner
2021-11-21 9:00 ` Jan Kiszka
2021-11-21 17:43 ` Lukas Wunner
2021-11-22 9:01 ` Su Bao Cheng
2021-11-22 17:11 ` Lukas Wunner
2021-12-13 16:12 ` 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=e1a9b9bf-45a4-6e71-09f4-1ae730284778@163.com \
--to=baocheng_su@163.com \
--cc=baocheng.su@siemens.com \
--cc=chao.zeng@siemens.com \
--cc=gregkh@linuxfoundation.org \
--cc=jan.kiszka@siemens.com \
--cc=linux-serial@vger.kernel.org \
--cc=lukas@wunner.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).