On Mon, Sep 21, 2020 at 02:17:07PM +0200, Oliver Neukum wrote: > Am Montag, den 21.09.2020, 14:03 +0200 schrieb Johan Hovold: > > 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. > > You mean 3.4.1? It's 3.3.1 in Version 1.1 at least. > > > > 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). > > Right, so let me be more specific. It would probably be unwise to > change the decision tree in probe() as far as devices whose quirks > affect decisions in that already are concerned. But we need to draw line somewhere to keep the code maintainable and ourselves sane, especially since a lot of these devices where added without any record of their descriptors. I guess we could add another test for the device-id fields, but I'm reluctant to add more special casing before we know it's needed. Johan
