| 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
| ||
|
Message-ID: <20200724131004.GB314889@kroah.com>
Date: Fri, 24 Jul 2020 15:10:04 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Sheng Long Wang <china_shenglong@....com>
Cc: johan@...nel.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, jan.kiszka@...mens.com,
Wang Sheng Long <shenglong.wang.ext@...mens.com>
Subject: Re: [PATCH] usb-serial:cp210x: add CP210x support to software flow
control
On Fri, Jul 24, 2020 at 06:29:46PM +0800, Sheng Long Wang wrote:
> From: Wang Sheng Long <shenglong.wang.ext@...mens.com>
>
> The cp210x driver lacks soft-flow function,so need and
> this function.
Why is this indented?
And I do not quite understand this sentance, why is this needed?
>
> Signed-off-by: Wang Sheng Long <shenglong.wang.ext@...mens.com>
> ---
> drivers/usb/serial/cp210x.c | 110 +++++++++++++++++++++++++++++++++---
> 1 file changed, 103 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index e732949f65..ad5db0e2ae 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -380,6 +380,9 @@ static struct usb_serial_driver * const serial_drivers[] = {
> #define CP210X_PARTNUM_CP2102N_QFN20 0x22
> #define CP210X_PARTNUM_UNKNOWN 0xFF
>
> +#define CP210X_VSTART 0x11
> +#define CP210X_VSTOP 0x13
No tabs?
> +
> /* CP210X_GET_COMM_STATUS returns these 0x13 bytes */
> struct cp210x_comm_status {
> __le32 ulErrors;
> @@ -391,6 +394,15 @@ struct cp210x_comm_status {
> u8 bReserved;
> } __packed;
>
> +struct cp210x_chars_respones{
> + u8 bEofchar;
> + u8 bErrochar;
> + u8 bBreakchar;
> + u8 bEventchar;
> + u8 bXonchar;
> + u8 bXoffchar;
Why the 'b' character here?
Is this coming from some public spec somewhere with these specific
fields?
> +} __packed;
> +
> /*
> * CP210X_PURGE - 16 bits passed in wValue of USB request.
> * SiLabs app note AN571 gives a strange description of the 4 bits:
> @@ -624,6 +636,43 @@ static int cp210x_read_vendor_block(struct usb_serial *serial, u8 type, u16 val,
> return result;
> }
>
> +/*
> + * Read and Write Characrters Respones operate
> + * Register SET_CHARS/GET_CHATS
> + */
> +static int cp210x_operate_chars_block(struct usb_serial_port *port, u8 req, u8 type,
> + void *buf, int bufsize)
> +{
> + struct usb_serial *serial = port->serial;
> + struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
> + void *dmabuf;
> + int result;
> +
> + dmabuf = kmemdup(buf, bufsize, GFP_KERNEL);
> + if (!dmabuf)
> + return -ENOMEM;
> +
> + result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
> + req, type, 0, port_priv->bInterfaceNumber, dmabuf, bufsize,
> + USB_CTRL_SET_TIMEOUT);
> + if (result == bufsize) {
> + if (type == REQTYPE_DEVICE_TO_HOST)
> + memcpy(buf, dmabuf, bufsize);
> +
> + result = 0;
> + } else {
> + dev_err(&port->dev, "failed get req 0x%x size %d status: %d\n",
> + req, bufsize, result);
> + if (result >= 0)
> + result = -EIO;
> +
> + }
> +
> + kfree(dmabuf);
> +
> + return result;
> +}
> +
> /*
> * Writes any 16-bit CP210X_ register (req) whose value is passed
> * entirely in the wValue field of the USB request.
> @@ -650,8 +699,8 @@ static int cp210x_write_u16_reg(struct usb_serial_port *port, u8 req, u16 val)
> * Writes a variable-sized block of CP210X_ registers, identified by req.
> * Data in buf must be in native USB byte order.
> */
> -static int cp210x_write_reg_block(struct usb_serial_port *port, u8 req,
> - void *buf, int bufsize)
> +static int cp210x_write_reg_block(struct usb_serial_port *port,
> + u8 req, void *buf, int bufsize)
> {
> struct usb_serial *serial = port->serial;
> struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
> @@ -1134,11 +1183,17 @@ static void cp210x_set_termios(struct tty_struct *tty,
> struct usb_serial_port *port, struct ktermios *old_termios)
> {
> struct device *dev = &port->dev;
> - unsigned int cflag, old_cflag;
> + struct cp210x_chars_respones CharsRes;
> + struct cp210x_flow_ctl flow_ctl;
> + unsigned int cflag, old_cflag, iflag;
> u16 bits;
> + int result;
> + u32 ctl_hs;
> + u32 flow_repl;
>
> cflag = tty->termios.c_cflag;
> old_cflag = old_termios->c_cflag;
> + iflag = tty->termios.c_iflag;
>
> if (tty->termios.c_ospeed != old_termios->c_ospeed)
> cp210x_change_speed(tty, port, old_termios);
> @@ -1212,10 +1267,6 @@ static void cp210x_set_termios(struct tty_struct *tty,
> }
>
> if ((cflag & CRTSCTS) != (old_cflag & CRTSCTS)) {
> - struct cp210x_flow_ctl flow_ctl;
> - u32 ctl_hs;
> - u32 flow_repl;
> -
> cp210x_read_reg_block(port, CP210X_GET_FLOW, &flow_ctl,
> sizeof(flow_ctl));
> ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
> @@ -1252,6 +1303,51 @@ static void cp210x_set_termios(struct tty_struct *tty,
> sizeof(flow_ctl));
> }
>
> + /* Set Software Flow Control
> + * Xon/Xoff code
> + * Check the IXOFF/IXON status in the iflag component of the
> + * termios structure.
> + *
> + */
> + if ((iflag & IXOFF) || (iflag & IXON)) {
> + /*set vstart/vstop chars */
> + result = cp210x_operate_chars_block(port, CP210X_GET_CHARS,
> + REQTYPE_DEVICE_TO_HOST, &CharsRes, sizeof(CharsRes));
> + dev_dbg(dev, "%s - bXonchar=0x%x bXoffchar=0x%x \n",
> + __func__, CharsRes.bXonchar, CharsRes.bXoffchar);
Are these dev_dbg() lines still needed now that the code is working?
And you never need a __func__ in a dev_* function, it can always display
that automatically if you need/want it. But here it's pointless.
thanks,
greg k-h
Powered by blists - more mailing lists