Am Mittwoch, 18. Januar 2012, 13:32:16 schrieb Bjørn Mork: > hat seems easier to handle in the cdc-wdm code. The usbnet code will > happily kill it all over the place, including dropping to resubmit > inside the completion handler if netif_running() says the network is > down. That makes it difficult to add the needed "do not kill if there > are open files" test. cdc-wdm is much cleaner in this aspect, and it > should be easy to add the test for a running network interface if > required. But I don't think it is unless we want to support usbnet > minidrivers requiring it. > > > I would also almost say it is fine to integrate cdc-wdm support directly > > into the network driver and activate it for certain VID:PID > > combinations. > > Yeah, after playing with this it seems very easy. Just leave the > interrupt endpoint for cdc-wdm to play with and let usbnet handle the > bulk endpoints. Not much job really: add cdc-wdm probe() and > disconnect() alternatives allowing this, and probably review all the pm > and reset methods to see if they need to know about the driver symbiosis. > > > Only real challenges are > > - only one driver/module can be allowed to do usb_set_intfdata(), and I > do not want to merge usbnet and cdc-wdm to the point that they both > use the same intfdata struct For what it's worth it should be mentioned that you are not alone in this problem. The media people face the same problem with serial devices as readers for chip cards in devices that do encryption. Those devices don't have an interface dedicated to the card reader. Alan, how hard would it be to "fake" a device that is a child of the real device, so that we could write a tiny driver for a "union" interface that would probe "subdrivers" using the generic probe() calls? Regards Oliver -- 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
