On Friday 23 July 2010, Greg KH wrote: > On Fri, Jul 23, 2010 at 12:28:18PM +0100, Andrew Bird (Sphere Systems) wrote: > > Hi Greg, > > > > I just discovered that the device can appear in two modes, depending on > > > > what usb_modeswitch packet is used to flip it into modem mode. I've > > attached two lsusb -v outputs of each config. In one mode I need to > > blacklist interface 1, in the other 1 & 2. I'm not sure this patch is > > the best way to handle that, have you any suggestions? > > I really don't know, sorry. Which mode works as a modem, that is what > you want to bind to, the other one, you don't. In mode 1 interfaces are as follows: 0 - modem(AT) 1 - network 2 - diagnostics port(qualcomm proprietary protocol) 3 - secondary port(AT) 4 - CDROM 5 - SDCARD Most mobile broadband connection software would use i/f 0 for data and i/f 3 for command/status. But in Windows land the data would be done using a pseudo network interface running on i/f 1 for higher throughput. In mode 2 interfaces are as follows 0 - modem(AT) 1 - network CDC master 2 - network CDC slave 3 - diagnostics port(qualcomm proprietary protocol) 4 - secondary port(AT) 5 - CDROM 6 - SDCARD So similarily std PPPD connections would use i/f 0 and signal strength/SMS etc would be done on i/f 4. The fact that now we have CDC interfaces exposed, raises the chances of getting usbnet/cdc_ether running on i/f 1 &2 So that's the problem, am I right to try and make 'option' bind to the correct interfaces for tty, and avoid the others, so a later driver can bind to the net interface(s)? Or should I be considering creating a thin new driver that probes then binds 'usb_wwan' to tty ports, and 'cdc_ether' to the net interface? Thanks, Andrew -- 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
