Oliver Neukum <oneukum@xxxxxxxx> writes: > On Di, 2018-06-26 at 09:40 +0200, Bjørn Mork wrote: >> This code can make Linux default to a MBIM configuration if the MBIM >> function uses the first interface in that configuration, even if this >> configuration is not the first one. Availability of a driver is not >> considered. Except for RNDIS, just to make it the whole mess even more >> confusing.... > > How would you consider it? We chose a configuration before we load > drivers. Even if we looked at the currently available drivers we'd end > up with a choice depending on which devices were used in the past. > A nondeterministic choice would be awkward. > > We can load drivers for all configurations' interfaces, but we cannot > really wait for the loads to happen at that stage. No, we do not want more driver support guesswork. Going back in time, I believe it would be far better to simply let the firmware decide the default by using the first configuration. It's the least surprising choice, and the likely tested configuration. And it would simplify the code. You are of course correct that we have no knowledge of available, matching, or successfully probing, drivers at this point. All the problems come from the attempt to consider driver availability anyway. The preference for class functions is clearly(?) based on an assumption that class drivers are more likely to be available. But I do realize that this was more difficult when the code was written. We did not support many vendor specific functions, and there wasn't mcuh reason to believe this would change over time. And it might have been more complicated/impossible to override the kernel default in userspace, writing to bConfigurationValue from something like udev? Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
