linux-kernel - Re: [PATCH] drivers: fix the hardware flow function of cp2102

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20200616100446.GB2614426@kroah.com>
Date:   Tue, 16 Jun 2020 12:04:46 +0200
From:   "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To:     "Gao, Nian" <nian.gao@...mens.com>
Cc:     "Johan@...nel.org" <Johan@...nel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Kiszka, Jan" <jan.kiszka@...mens.com>
Subject: Re: [PATCH] drivers: fix the hardware flow function of cp2102

On Tue, Jun 16, 2020 at 08:37:39AM +0000, Gao, Nian wrote:
> >From 97278cc3d00d22e8fc1edecce1f08772823a50dd Mon Sep 17 00:00:00 2001
> From: Gao Nian <nian.gao@...mens.com>
> Date: Tue, 16 Jun 2020 16:29:42 +0800
> Subject: [PATCH] drivers: fix the hardware flow function of cp2102

Why is this all in the body of your email?

Please just use git send-email to send patches out so that they come in
the proper format.

As it is, your patch has all of the tabs changed to spaces, making it
impossible to apply.  Please fix your email client up to not do this.


> 
> When the recieve buffer is full in hardware flow mode,
> cp2102 will not activate the RTS signal to notify
> the sender to stop sending data.
> 
> Signed-off-by: Gao Nian <nian.gao@...mens.com>
> ---
> drivers/usb/serial/cp210x.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index f5143eedbc48..c3e05e135d2d 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -272,6 +272,8 @@ static struct usb_serial_driver cp210x_device = {
>            .break_ctl                     = cp210x_break_ctl,
>            .set_termios                 = cp210x_set_termios,
>            .tx_empty                     = cp210x_tx_empty,
> +          .throttle                         = usb_serial_generic_throttle,
> +          .unthrottle                     = usb_serial_generic_unthrottle,
>            .tiocmget                      = cp210x_tiocmget,
>            .tiocmset                      = cp210x_tiocmset,
>            .attach                          = cp210x_attach,
> @@ -915,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);
> @@ -1013,8 +1016,20 @@ static void cp210x_get_termios_port(struct usb_serial_port *port,
>            cp210x_read_reg_block(port, CP210X_GET_FLOW, &flow_ctl,
>                                    sizeof(flow_ctl));
>            ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
> +          flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
> +          /*
> +          * CP210x hardware disables RTS but leaves CTS when in hardware flow
> +          * control mode and port is closed.
> +          * This allows data to flow out, but new data will not come into the port.
> +          * When re-opening the port, if CTS is enabled, then RTS must manually be
> +          * re-enabled.
> +          */
>            if (ctl_hs & CP210X_SERIAL_CTS_HANDSHAKE) {
> -                       dev_dbg(dev, "%s - flow control = CRTSCTS\n", __func__);

Why remove this debugging line?

thanks,

greg k-h