> If there is no better way, I think I'll have to implement "proxy interfaces" > which determine the type of interface the respective instance implements and > call the correct functions. > > I have also considered the alternative of using two drivers, but the problem > is > that the serial function and the network function share a USB interface, so > I'd > need something like a "per-endpoint driver binding" (which I believe would be > complete nonsense). If I have not missed an important aspect, then what > usb_mid > does is not sufficient.
Is this device CDC (Communication Device Class) compliant or vendor specific? What do USB descriptors look like? Does prtconf show interfaces under usb_mid? With CDC, I think, the device would present separate USB interfaces for different subclass codes (ACM, Ethernet, etc) within CDC class, in which case you'd bind two drivers to two interfaces - as opposed to binding a multipurpose driver to the whole device. If you have a poorly designed vendor-specific device with multiple functions but no corresponding interfaces, I think the cleanest approach would be to implement a nexus driver, similar in purpose to usb_mid, that would create two interface nodes and enable you to bind two drivers. -Artem _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
