From: Johan Hovold <johan@kernel.org>
To: Phu Luu <Phu.Luu@silabs.com>
Cc: "johan@kernel.org" <johan@kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Brant Merryman" <Brant.Merryman@silabs.com>,
"Richard Hendricks" <Richard.Hendricks@silabs.com>,
"Phú Lưu An" <luuanphu@gmail.com>,
"hungnd3@fsoft.com.vn" <hungnd3@fsoft.com.vn>
Subject: Re: [PATCH v3 2/2] USB: serial: cp210x: Proper RTS control when buffers fill
Date: Mon, 6 Jul 2020 12:18:34 +0200 [thread overview]
Message-ID: <20200706101834.GI3453@localhost> (raw)
In-Reply-To: <20200626074206.GP3334@localhost>
On Fri, Jun 26, 2020 at 09:42:06AM +0200, Johan Hovold wrote:
> On Fri, Jun 26, 2020 at 04:24:20AM +0000, Phu Luu wrote:
> > From: Brant Merryman <brant.merryman@silabs.com>
> >
> > CP210x hardware disables auto-RTS but leaves auto-CTS when
> > in hardware flow control mode and UART on cp210x hardware
> > is disabled. This allows data to flow out, but new data
> > will not come into the port. When re-opening the port, if
> > auto-CTS is enabled on the cp210x, then auto-RTS must be
> > re-enabled in the driver.
> >
> > Signed-off-by: Phu Luu <phu.luu@silabs.com>
> > Signed-off-by: Brant Merryman <brant.merryman@silabs.com>
>
> Please revisit these tags as well.
>
> > ---
> > 06/09/2020: Patch v3 2/2 Modified based on feedback from Johan Hovold <johan@kernel.org>
> > 12/18/2019: Patch v2 Broken into two patches and modified based on feedback from Johan Hovold <johan@kernel.org>
> > 12/09/2019: Initial submission of patch "Proper RTS control when buffers fill"
> >
> > drivers/usb/serial/cp210x.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> > index bcceb4ad8be0..091441b1c5b9 100644
> > --- a/drivers/usb/serial/cp210x.c
> > +++ b/drivers/usb/serial/cp210x.c
> > @@ -917,6 +917,7 @@ static void cp210x_get_termios_port(struct usb_serial_port *port,
> > u32 baud;
> > u16 bits;
> > u32 ctl_hs;
> > + u32 flow_repl;
> >
> > cp210x_read_u32_reg(port, CP210X_GET_BAUDRATE, &baud);
> >
> > @@ -1017,6 +1018,23 @@ static void cp210x_get_termios_port(struct usb_serial_port *port,
> > ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
> > if (ctl_hs & CP210X_SERIAL_CTS_HANDSHAKE) {
> > dev_dbg(dev, "%s - flow control = CRTSCTS\n", __func__);
> > + /*
> > + * When the port is closed, the CP210x hardware disables
> > + * auto-RTS and RTS is deasserted but it leaves auto-CTS when
> > + * in hardware flow control mode. This prevents new data from
> > + * being received by the port. When re-opening the port, if
> > + * auto-CTS is enabled on the cp210x, then auto-RTS must be
> > + * re-enabled in the driver.
> > + */
>
> I already asked this of Brant, but could you please be more specific
> about which state the RTS-line end up in when disabling the UART (e.g.
> 0x00: statically inactive)?
>
> The reason I ask is that after open() returns, the tty layer would raise
> RTS, which should again allow data to flow in in contrast to what the
> comment and changelog text claims.
I had another reason to look at this driver so I could determine that
the patch description and comment were indeed incorrect; the tty layer
asserts RTS when reopening the port just fine and data flows in.
> We still want to enable auto-RTS of course so the patch is otherwise
> correct.
I've fixed up the commit message and comment, reordered the SOB tags
and added your Co-developed-by tag before applying both of these now:
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/log/?h=usb-next
Johan
next prev parent reply other threads:[~2020-07-06 10:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 4:24 [PATCH v3 2/2] USB: serial: cp210x: Proper RTS control when buffers fill Phu Luu
2020-06-26 7:42 ` Johan Hovold
2020-07-06 10:18 ` Johan Hovold [this message]
[not found] ` <CAP847ynZDozdA0kDEo6Zjuk0LOeaiTyW_fnU89hnFUD8ntL8uw@mail.gmail.com>
2020-08-17 9:55 ` Johan Hovold
[not found] <DM6PR11MB2857CC4B06D64F290FC42E739C950@DM6PR11MB2857.namprd11.prod.outlook.com>
2020-06-24 7:09 ` gregkh
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=20200706101834.GI3453@localhost \
--to=johan@kernel.org \
--cc=Brant.Merryman@silabs.com \
--cc=Phu.Luu@silabs.com \
--cc=Richard.Hendricks@silabs.com \
--cc=gregkh@linuxfoundation.org \
--cc=hungnd3@fsoft.com.vn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=luuanphu@gmail.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 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).