On Mon, Sep 21, 2020 at 07:17:37PM +0200, Oliver Neukum wrote:
> Am Montag, den 21.09.2020, 17:16 +0200 schrieb Johan Hovold:
> > > > interface? By hardcoding the data-interface number to be the one and
> > > > only interface, you'd end up probing for a "combined" interface also
> > > > with a broken call-management descriptor.
> > >
> > > Well, by the changelog assuming a combined interface caused an oops.
> > > Thence I am forced to conclude that the davices _has_ a separate
> > > data interface, but no union descriptor.
> >
> > No, the oops was probably due to the missing sanity check later added by
> > 403dff4e2c94 ("USB: cdc-acm: check for valid interfaces").
> >
> > With a broken call-management descriptor pointing to a non-existent
> > interface we'd oops before that commit.
>
> Hi,
>
> maybe I am dense, but a patch that comes after a patch that is said to
> fix something? Furthermore that patch would not come it work,
> it would merely make probe() fail cleanly. If I read the changelog
> correctly, the change makes the device work.
The relevant commits are
a2bfb4a346d2 ("USB: support for cdc-acm of single interface devices") (2009)
fd5054c169d2 ("USB: cdc_acm: Fix oops when Droids MuIn LCD is connected") (2011)
403dff4e2c94 ("USB: cdc-acm: check for valid interfaces") (2014)
Before Greg added the sanity checks in that last commit, a broken
call-management descriptor referring to a non-existent interface would
cause a NULL-pointer dereference.
The second commit, adding support for a specific device, didn't fix that
problem generally and only worked around it for one device by hardcoding
the data interface to match the control interface, thereby falling back
to the "combined-interface" probing you added in that first commit.
See? The second commit fixed the oops *and* made the device probe
successfully. If we'd had the sanity check in place by then it would
only have make it probe successfully.
Johan
