On Wed, Sep 12, 2018 at 10:34:43PM +0200, Bjørn Mork wrote: > Dan Williams <dcbw@xxxxxxxxxx> writes: > > > The fact that the firmware implementation has the ability to change the > > endpoints is unrelated to Kristian's case, and that alone is > > justification for this to be quirked in the driver. People other than > > Kristian will undoubtedly use the functionality, on platforms less > > limited. > > FWIW, I agree with Dan and Kristian on this. It's a documented feature, > and it will be used. The reasons are irrelevant. The firmware > implementation is inconvenient, but we should still strive to make it > Just Work in Linux. Kristian's solution does that. > > > Also most Huawei modems have the ability to change their layout and > > configuration just like the EP06 via the U2DIAG and SETPORT commands. > > Yes, but they are nice enough to use unique class/subclass/protocol > triplets for their functions so it's easy to support the changing > layout. At least as long as they use their own VID and not some laptop > vendor's.. > > The Sierra Wireless strategy, using fixed interface numbers leaving > "holes" is another fine solution to the problem. Or they could have > allocated unique VIDs per function combination, as long as the number of > valid combinations are low. But they didn't. It's not like it's the > first bad firmware design we've had to deal with. Let's just work > around it, like we always do. No need to make life difficult for end > users just because Quectel makes life difficult for us. Ok, thanks for everyone for your input. As Lars I was sceptical about this, but if this is contained to Quectel and we have a solutions which hopefully covers all permutations for their other devices, let's go along with this. I'd prefer seeing this contained in the device-id table as far as possible rather than maintaining a second table of product ids in probe() so I've cooked up a patch (on top of this one) adding a new device-id match flag. Kristian would you mind giving it a try? Oh, also note that I dropped the RSVD(5) for the ADB interface in your patch since it uses a different subclass anyway. I'll submit both patches in a series. Thanks, Johan
