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) 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. 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? But if we do that, then we do handle QMI+ECM and AT+ECM devices differently, so maybe separate drivers makes sense anyway? 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
