mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Lode Willems <me@lodewillems.com>
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND] USB: serial: CH341: add hardware flow control RTS/CTS
Date: Sat, 14 Dec 2024 18:21:09 +0100	[thread overview]
Message-ID: <Z12-hZKS83WQ5bYd@hovoldconsulting.com> (raw)
In-Reply-To: <20241113180930.3741-1-me@lodewillems.com>

On Wed, Nov 13, 2024 at 07:08:27PM +0100, Lode Willems wrote:
> This adds support for enabling and disabling
> RTS/CTS hardware flow control.
> Tested using a CH340E in combination with a CP2102.
> 
> Fixes part of the following bug report:
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=197109
> 
> Signed-off-by: Lode Willems <me@lodewillems.com>

Thanks for the patch and sorry about the late feedback on this one. I
wanted to give it a spin with the devices I have here (ch340g and
ch341a).

Appears to the modem control lines are not wired up on the ch341a
evaluation board I have, but the device accepts the request and stops
transmitting with hardware flow control enabled.

With ch340g in loopback, I also see it refuse to transmit unless cts is
asserted. I was not able to get the device to deassert rts when
attempting to fill its receive buffers, however. Perhaps the hardware
does not support this, but is this something you tried?

> ---
>  drivers/usb/serial/ch341.c | 41 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
> index d10e4c4848a0..62237f657320 100644
> --- a/drivers/usb/serial/ch341.c
> +++ b/drivers/usb/serial/ch341.c
> @@ -63,6 +63,7 @@
>  #define CH341_REG_DIVISOR      0x13
>  #define CH341_REG_LCR          0x18
>  #define CH341_REG_LCR2         0x25
> +#define CH341_REG_FLOW_CTL     0x27
>  
>  #define CH341_NBREAK_BITS      0x01
>  
> @@ -77,6 +78,9 @@
>  #define CH341_LCR_CS6          0x01
>  #define CH341_LCR_CS5          0x00
>  
> +#define CH341_FLOW_CTL_NONE    0x000
> +#define CH341_FLOW_CTL_RTSCTS  0x101

The registers are eight bits wide, but the driver writes two at a time.
So this should just be 0x00 and 0x01.

> +
>  #define CH341_QUIRK_LIMITED_PRESCALER	BIT(0)
>  #define CH341_QUIRK_SIMULATE_BREAK	BIT(1)
>  
> @@ -478,6 +482,41 @@ static int ch341_open(struct tty_struct *tty, struct usb_serial_port *port)
>  	return r;
>  }
>  
> +static void ch341_set_flow_control(struct tty_struct *tty,
> +				   struct usb_serial_port *port,
> +				   const struct ktermios *old_termios)
> +{
> +	int r;
> +
> +	if (old_termios &&
> +	    C_CRTSCTS(tty) == (old_termios->c_cflag & CRTSCTS))
> +		return;

Just drop this and set the requested setting unconditionally.

> +
> +	if (C_CRTSCTS(tty)) {
> +		r = ch341_control_out(port->serial->dev, CH341_REQ_WRITE_REG,
> +				      CH341_REG_FLOW_CTL |
> +				      ((u16)CH341_REG_FLOW_CTL << 8),
> +				      CH341_FLOW_CTL_RTSCTS);
> +		if (r < 0) {
> +			dev_err(&port->dev,
> +				"%s - failed to enable flow control: %d\n",
> +				__func__, r);
> +			tty->termios.c_cflag &= ~CRTSCTS;
> +		}
> +	} else {
> +		r = ch341_control_out(port->serial->dev, CH341_REQ_WRITE_REG,
> +				      CH341_REG_FLOW_CTL |
> +				      ((u16)CH341_REG_FLOW_CTL << 8),
> +				      CH341_FLOW_CTL_NONE);
> +		if (r < 0) {
> +			dev_err(&port->dev,
> +				"%s - failed to disable flow control: %d\n",
> +				__func__, r);
> +			tty->termios.c_cflag |= CRTSCTS;
> +		}
> +	}

Please rewrite this so that you prepare the value and index parameters
based on the termios settings and then do one control request. If it
fails you can restore the old setting (if old_termios is non-NULL).

And please drop the redundant __func__ from the error message (even if
the driver still uses it in some other functions still).

> +}
> +

Johan

  reply	other threads:[~2024-12-14 17:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-13 18:08 Lode Willems
2024-12-14 17:21 ` Johan Hovold [this message]
2024-12-17 20:08   ` Lode Willems
2024-12-18 14:20     ` Johan Hovold

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=Z12-hZKS83WQ5bYd@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=me@lodewillems.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

all inboxes | Powered by JetHome®