Oliver Neukum <oliver@xxxxxxxxxx> writes: > On Tuesday 04 September 2012 17:32:17 Bjørn Mork wrote: >> Oliver Neukum <oneukum@xxxxxxx> writes: >> > On Tuesday 04 September 2012 15:45:36 Bjørn Mork wrote: > >> >> USB_CDC_NOTIFY_NETWORK_CONNECTION and USB_CDC_NOTIFY_SPEED_CHANGE. >> >> cdc-wdm will just debug print USB_CDC_NOTIFY_NETWORK_CONNECTION and >> >> ignore it, but will log an error if it sees USB_CDC_NOTIFY_SPEED_CHANGE >> > >> > So provide callbacks for them. >> >> It seems a littly overkill to provide a separate callback for each of >> these, so how about using the same callback but call it only for the >> notifications we know a main driver may be interested in? I.e. something >> along the lines > > No. Once we've decided that multiple callbacks are needed, there's no use in > limiting their number. It is importantant that they get clear semantics and > reasonable names. You've already introduced a structure for them. So beef it up. > >> Should I take it in again, and submit a new version for further >> comments? Still won't have any sample code using the API, I'm afraid. > > Please propose a version with the callbacks you'll need all separated. Just a FYI in case you wonder where this went... Re-reading the MBIM specification it became clear that the need for USB_CDC_NOTIFY_NETWORK_CONNECTION and USB_CDC_NOTIFY_SPEED_CHANGE callbacks was a misunderstanding. These are used by NCM but not required for MBIM. So they can be dropped. And after implementing MBIM control channel snooping, doing magic device creation based on the snooped messages, I realized that those who warned me about doing that were right. The idea is currently dropped, and with it the need for any cdc_wdm data snooping. So it seems we can do MBIM just fine with the existing cdc_wdm subdriver API. Sorry for the unnecessary noise this discussion caused, and thanks for all the valuable feedback as usual. 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
