Re: [PATCH v2] USB: cdc-acm: add Whistler radio scanners TRX series support

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 13:36:01 +0200	[thread overview]
Message-ID: <20200921113601.GT24441@localhost> (raw)
In-Reply-To: <1600684156.2424.65.camel@suse.com>

On Mon, Sep 21, 2020 at 12:29:16PM +0200, Oliver Neukum wrote:
> Am Montag, den 21.09.2020, 11:31 +0200 schrieb Johan Hovold:
> > On Mon, Sep 21, 2020 at 10:43:12AM +0200, Oliver Neukum wrote:
> > > Am Montag, den 21.09.2020, 10:10 +0200 schrieb Johan Hovold:
> > > > Add support for Whistler radio scanners TRX series, which have a union
> > > > descriptor that designates a mass-storage interface as master. Handle
> > > > that by generalising the NO_DATA_INTERFACE quirk to allow us to fall
> > > > back to using the combined-interface detection.
> > > 
> > > Hi,
> 
> Hi,
> 
> > > 
> > > it amazes me what solutions people can come up with. Yet in this case
> > > using a quirk looks like an inferior solution. If your master
> > > is a storage interface, you will have a condition on the device you
> > > can test for without the need for a quirk.
> > 
> > Sure, and I mentioned that as an alternative, another would be checking
> > for a control interface with three endpoints directly.
> 
> These tests are not mutually exclusive. You can check for both
> conditions being met. In fact you have to, it seems to me.

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 management descriptors and all the ways
that devices may have gotten those wrong.

I'll include that as an RFC.

> > My fear is that any change in this direction risk introducing regression
> > if there are devices out there with broken descriptors that we currently
> > happen to support by chance. Then again, probably better to try to
> > handle any such breakage if/when reported.
> 
> Well, I guess the chance that we break devices which claim to be
> storage devices we will simply have to take. Those devices are
> quite broken in any case.

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.

Johan