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? > qmi_wwan => QMI > cdc_mbim => MBIM > huawei_cdc_ncm => AT > > > ModemManager does not currently support AT-capable cdc-wdm interfaces > > though, since the SE devices didn't use them for the primary/secondary > > AT ports. > > > >> I expected this type of device might exist, but we haven't really tried > >> to support it before (AFAIK). Although the qmi_wwan driver doesn't care > >> about whether the embedded control protocol is QMI or AT or something > >> else, current userspace applications do. I am not entirely sure about > >> how this should be handled, but it should be sorted out before we start > >> adding non QMI devices to the driver. > > > > If we start adding non-QMI devices to the driver, then we should rename > > it to something more generic. Or, better yet, make the driver generic, > > and keep qmi_wwan a sub-driver with all the current device IDs. > > 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. > 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? Was it simply the case that, at the time, nobody else was doing quasi-ECM except Qualcomm? Dan > Hmm, as usual I don't know what I want... > > > 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
