On Mon, 2013-11-11 at 18:41 +0100, Bjørn Mork wrote: > Dan Williams <dcbw@xxxxxxxxxx> writes: > > On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote: > >> Dan Williams <dcbw@xxxxxxxxxx> writes: > >> > On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: > >> > > >> >> Maybe run a small discussion on the ModemManager list first? This would > >> >> be the first non-QMI device there, and I don't think userspace is > >> >> prepared for that.... > >> > > >> > We've got a bug open for this in ModemManager: > >> > > >> > https://bugzilla.gnome.org/show_bug.cgi?id=699741 > >> > > >> > Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and > >> > many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so > >> > this device wouldn't be the first to expose an AT-capable cdc-wdm port. > >> > >> Yes, I am fully aware of this. But currently there is an assumed > >> relationship between driver and cdc-wdm protocol: > >> > >> cdc-wdm => AT (except for the unfortunate v3.4+5 Huawei QMI case) > > > > Assumed where? kernel or ModemManager? > > Maybe just in my head :-) > > I thought ModemManager based it's decisions wrt protocol on the driver? It's a mix of driver names, device names, and udev rules. For example, ModemManager currently only cares about devices named "cdc-wdm*" when the USB device is driven by qmi_wwan or cdc_mbim. Otherwise these ports are ignored (as is the case for Ericsson devices). And this check only sets probing flags, so this could easily be extended to probe "cdc-wdm" devices for AT commands too. One example of solely driver-based detection is the 'hso' driver, which only drives Option HSO devices. In this case, ModemManager uses the driver name as the filter. > >> This puts way too much into the driver name, IMHO. I don't think > >> renaming the driver or creating two distinct driver names for AT or QMI > >> devices makes much sense, given that these drivers will be identical. > >> FWIW it's just a coincidence that the qmi_wwan driver didn't end up > >> being named huawei_something instead. > > > > Yeah, might be a coincidence but a driver name of "qmi_wwan" driving > > non-QMI devices still seems quite wrong. "option" driving non-option > > devices was also wrong, but at the time nobody pushed back on that. The > > correct solution at the time would have been to rename 'option' to > > wwan_serial or something like that. If we're going to pursue this, lets > > make the qmi_wwan driver a generic name instead. > > Well, I am sure you are right. I've been wrong before :) > >> We could make the protocol (if known) an attribute of the cdc-wdm > >> device, either in sysfs or adding another ioctl. A sysfs attribute > >> would have been nice, but I guess the discussion around the message size > >> attribute applies here too? > > > > While might be nice, it does have drawbacks and it's harder to get > > mistakes corrected if they are done in the kernel, due to how > > (in)frequently people update their kernels. I guess I'd say we stick > > with userspace solutions for this for now, even if it does duplicate the > > VID/PID lists or use probing. > > > >> But if we do that, then we do handle QMI+ECM and AT+ECM devices > >> differently, so maybe separate drivers makes sense anyway? > > > > So the net-port parts of qmi_wwan just do "standard" ECM then? > > Yes. Only the descriptors are weird. The rest is standard ECM. Well, including all the IPv4/IPv6 quirks? Those seem to be Qualcomm specific; especially where the rawip/8023 and QoS options are concerned. Were we ever to support rawip or the QoS options, we'd need a completely different driver. My suggestion here would be to create a new "cdc-ecm" driver (like we did for cdc_eem or cdc_ether or cdc_ncm) and make qmi_wwan a sub-driver of that (if that's even needed given these all are subdrivers of usbnet). This way we keep "standard" ECM in one place and pile all the vendor-specific hacks into sub-drivers instead of tangling them all together? Dan > > Was it > > simply the case that, at the time, nobody else was doing quasi-ECM > > except Qualcomm? > > Limited by the devices I knew of. > > > 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
