On Wed, 2013-02-13 at 15:27 +0100, Oliver Neukum wrote: > On Saturday 09 February 2013 20:16:20 Bjørn Mork wrote: > > Oliver Neukum <oliver@xxxxxxxxxx> writes: > > > On Saturday 09 February 2013 18:41:52 Bjørn Mork wrote: > > > Well, OK..., "generic" then. In the sense that the attribute stays the > > same regardless of whether the value is hardcoded in the driver (QMI), > > or parsed from wMaxCommand (CDC WDM) or wMaxControlMessage (CDC MBIM) > > > > Not sure I understand what you want here... I am trying to avoid having > > three different attributes for the three drivers currently needing this > > number. > > I would say that the most generic solution would be an ioctl() > > > > Really, ideally user space would not know what driver is handling > > > the control channel. > > > > Well, as it is now user space has a long tradition for looking at driver > > names. ModemManager has done that for quite while when it comes to > > serial drivers, because the driver name is one of the few information > > sources available telling it something about the expected protocols. > > But that has caused the problems. If you get cdc-acm, you know nothing. And that's why ModemManager probes serial ports, to see if they support AT or DIAG or whatever. We long ago tried "tagging" modems via udev rules, but that's a losing battle as the interfaces sometimes switch around with firmware updates, or the OEM (*cough* Huawei *cough* ZTE *cough*) use the same VID/PID for wildly different devices with different port layouts. Plus, many many mobile phones use the same VID/PID for quite different devices too. Obviously for certain drivers (sierra, qcaux, qmi_wwan, hso) we know exactly what kind of device is connected. Dan -- 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
