Alexey Orishko <alexey.orishko@xxxxxxxxx> writes: > On Tue, Sep 4, 2012 at 3:45 PM, Bjørn Mork <bjorn@xxxxxxx> wrote: > >> Yes. But this time with some hope of multi-vendor support, given that >> Microsoft points to it for Windows 8 Mobile Broadband device support: >> http://msdn.microsoft.com/en-us/library/windows/hardware/mbim-based-mobile-broadband-requirements-for-windows.aspx > It looks like mandatory feature for W8 logo tests, so vendors must adapt to it That was my interpretation as well, but I never understand these commercial issues so I wouldn't be surprised if some vendor found some other solution. Anyway, as things are looking right now we need to support this protocol in Linux for the next (or next-next?) generation of mobile broadband devices. >> Yes, I expect that major changes to cdc_ncm will be necessary, and >> pointing to it could be wrong from my side? It just seemed natural to >> try to reuse any existing code. > > MBIM CID handling should not be done in the driver, but in the user space daemon > or connection manager application. Exactly! That is the main target of this excercise. > So the need is to add only support > for encapsulated > commands and either use a static amount of network interfaces or create them > dynamically based on CID parser commands to the driver. > It also requires updates for constructing headers, etc, but it's simple change. Yes, something like that is required. Greg S will probably come up with some good ideas here :-) >>>> CDC MBIM features we are going to support, there is also a possibility >>>> that the main driver will have to intercept messages between the >>>> userspace and the cdc-wdm subdriver. >>> >>> Ouch. > Why do we need cdc-wdm driver? It would be too complex to handle all > required data. > We already handling several control requests, so adding one more won't > be a problem. > And we have to expose some control interface towards user space from > mbim driver. That's what we use the cdc-wdm driver for. It takes the CDC encapsulated MBIM control protocol and export it as a character device to the userspace application. The ideal case is the one we have in qmi_wwan, where cdc-wdm exports the QMI protocol without either qmi_wwan or cdc-wdm knowing anything about the protocol at all. I hope we can get as close to that for MBIM too, only looking at one (or a limited set of) specific messages from the device to know when to add or remove a network device. >> yes. Reading the spec terrified me. Among other issues, it allows >> multiplexing several IP connections over a single set of bulk in/out >> endpoints, where an "IP connection" probably will have to map logically >> to a network device. > Yes, it means we get more than one virtual network interface. Right. So the driver will not necessarily create network devices on probe, but instead when it sees a MBIM message from the device indicating a successful IP session start. 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
