From: Johan Hovold <johan@kernel.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB: serial: pl2303: account for deficits of clones
Date: Mon, 9 Sep 2024 14:32:59 +0200 [thread overview]
Message-ID: <Zt7q-5kk5SPgE7P4@hovoldconsulting.com> (raw)
In-Reply-To: <a07922bd-4550-41d8-a7cd-8943baf6f8fb@siemens.com>
On Sun, Sep 01, 2024 at 11:11:29PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> There are apparently incomplete clones of the HXD type chip in use.
> Those return -EPIPE on GET_LINE_REQUEST and BREAK_REQUEST. Avoid
> flooding the kernel log with those errors. Rather use the
> line_settings cache for GET_LINE_REQUEST and signal missing support by
> returning -ENOTTY from pl2303_set_break.
This looks mostly fine to me, but could you please try to make these
changes only apply to the clones or, since those probably cannot be
detected reliably, HXD?
What is the 'lsusb -v' for these devices?
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> drivers/usb/serial/pl2303.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> index d93f5d584557..04cafa819390 100644
> --- a/drivers/usb/serial/pl2303.c
> +++ b/drivers/usb/serial/pl2303.c
> @@ -731,12 +731,13 @@ static int pl2303_get_line_request(struct usb_serial_port *port,
> GET_LINE_REQUEST, GET_LINE_REQUEST_TYPE,
> 0, 0, buf, 7, 100);
> if (ret != 7) {
> - dev_err(&port->dev, "%s - failed: %d\n", __func__, ret);
> + struct pl2303_private *priv = usb_get_serial_port_data(port);
>
> - if (ret >= 0)
> - ret = -EIO;
> + dev_dbg(&port->dev, "%s - failed, falling back on cache: %d\n",
> + __func__, ret);
> + memcpy(buf, priv->line_settings, 7);
>
> - return ret;
> + return 0;
> }
Looking at the driver, it seems like we could move the only call to this
function to probe, and perhaps then an error message for cloned devices
is not such a big deal. But even that could be suppressed based on the
type.
Or we could use this call failing to flag the device as a likely clone
and use that flag to also skip break signalling completely.
> dev_dbg(&port->dev, "%s - %7ph\n", __func__, buf);
> @@ -1078,8 +1079,8 @@ static int pl2303_set_break(struct usb_serial_port *port, bool enable)
> BREAK_REQUEST, BREAK_REQUEST_TYPE, state,
> 0, NULL, 0, 100);
> if (result) {
> - dev_err(&port->dev, "error sending break = %d\n", result);
> - return result;
> + dev_dbg(&port->dev, "error sending break = %d\n", result);
> + return -ENOTTY;
> }
And similar here, the log level could depend on the type, unless the
function should just bail out early for clones.
>
> return 0;
Johan
next prev parent reply other threads:[~2024-09-09 12:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-01 21:11 [PATCH] USB: serial: pl2303: account for deficits of clones Jan Kiszka
2024-09-02 6:06 ` Greg Kroah-Hartman
2024-09-02 6:28 ` Jan Kiszka
2024-09-02 6:37 ` Greg Kroah-Hartman
2024-09-09 12:32 ` Johan Hovold [this message]
2024-09-09 12:52 ` Jan Kiszka
2024-09-09 13:43 ` Johan Hovold
2024-09-09 14:37 ` Jan Kiszka
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=Zt7q-5kk5SPgE7P4@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jan.kiszka@siemens.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/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