None of these are critical, so I don't think they are appropriate for 3.5 at this point. I've therefore based them on net-next. The two first patches prepare the driver for the new probing model introduced by patch #3, which is the main change in this set. A RFC version of this was posted to linux-usb 29 May 2012 for discussion, as it also implicitly affects the cdc-wdm driver, without any comments so far. Probing on the data interface was a mistake which was introduced at a point where I didn't realize that the cdc-wdm subdriver support was required in any case, because most of the supported devices only provide a single USB interface. Apart from creating a confusing and inconsistent driver usage, where some devices would use cdc-wdm as a subdriver and some would not, a number of real problems has also shown up. The most important one at the moment is the need to make cdc_ether and qmi_wwan cooperate wrt which devices are supported by which driver. This is close to impossible unless the two probes both look at the same control interface. It is not enough that the probe does this. We need to fine tune the alias matching, which implies fine tuning the device ID tables. Completing this change will require removing the now unnecessary and conflicting device ID entries from cdc-wdm. This will be submitted as a separate patch against usb-next to avoid mixing patches for both trees in one patch set. There is no build dependency. The two last patches are minor obvious editorial fixes. Bjørn Mork (5): net: qmi_wwan: define a structure for driver specific state net: qmi_wwan: rearranging to prepare for code sharing net: qmi_wwan: bind to both control and data interface net: qmi_wwan: shorten driver description net: qmi_wwan: use module_usb_driver macro drivers/net/usb/qmi_wwan.c | 308 +++++++++++++++++++++++--------------------- 1 file changed, 163 insertions(+), 145 deletions(-) -- 1.7.10 -- 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
