From: Johan Hovold <johan@kernel.org>
To: Oliver Neukum <oneukum@suse.com>
Cc: Johan Hovold <johan@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org,
Daniel Caujolle-Bert <f1rmb.daniel@gmail.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v2] USB: cdc-acm: add Whistler radio scanners TRX series support
Date: Mon, 21 Sep 2020 14:03:02 +0200 [thread overview]
Message-ID: <20200921120302.GU24441@localhost> (raw)
In-Reply-To: <1600688954.2424.76.camel@suse.com>
On Mon, Sep 21, 2020 at 01:49:14PM +0200, Oliver Neukum wrote:
> Am Montag, den 21.09.2020, 13:36 +0200 schrieb Johan Hovold:
> > On Mon, Sep 21, 2020 at 12:29:16PM +0200, Oliver Neukum wrote:
>
> Hi,
>
> > I meant that instead of falling back to "combined-interface" probing we
> > could assume that all interfaces with three endpoints are "combined" and
> > simply ignore the union and call managementy. descriptors and all the ways
> > that devices may have gotten those wrong.
>
> I am afraid we would break the spec. I cannot recall a prohibition on
> having more endpoints than necessary. Heuristics and ignoring invalid
> descriptors is one things. Ignoring valid descriptors is something
> else.
That depends on how you read the spec (see "3.3.1 Communication Class
Interface"). But sure, it's probably be better to err on the safe-side.
> > I was thinking more of the individual entries in the device-id table
> > whose control interfaces may not even be of the Communication class. But
> > hopefully that was verified when adding them.
>
> Now you are confusing me. In case of a quirky device, why change
> the current logic?
Just because they have a quirk defined, doesn't mean they don't rely on
the generic probe algorithm (e.g. a USB_DEVICE entry which matches all
interface classes and only specifies SEND_ZERO_PACKET).
Johan
next prev parent reply other threads:[~2020-09-21 12:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 8:10 [PATCH v2] USB: cdc-acm: add Whistler radio scanners TRX series support Johan Hovold
2020-09-21 8:43 ` Oliver Neukum
2020-09-21 9:31 ` Johan Hovold
2020-09-21 10:29 ` Oliver Neukum
2020-09-21 11:36 ` Johan Hovold
2020-09-21 11:49 ` Oliver Neukum
2020-09-21 12:03 ` Johan Hovold [this message]
2020-09-21 12:17 ` Oliver Neukum
2020-09-21 13:43 ` Johan Hovold
2020-09-25 14:49 ` Greg Kroah-Hartman
2020-09-25 14:53 ` Johan Hovold
2020-09-25 15:00 ` Greg Kroah-Hartman
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=20200921120302.GU24441@localhost \
--to=johan@kernel.org \
--cc=f1rmb.daniel@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=stable@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.