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? >> 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. >> 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. > 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
