Dan Williams <dcbw@xxxxxxxxxx> writes: > On Tue, 2009-01-27 at 14:49 -0800, Greg KH wrote: >> On Tue, Jan 27, 2009 at 07:20:20PM +0100, Bjørn Mork wrote: >> > I just got a laptop with one of these cards. In recent kernels this >> > seems to be handled by the option driver, after commit >> > b064eca9b0cdbb2b8f731ae2e44fa02194a1219a >> > added its vid/pid to this driver. This commit makes the card >> > non-functional as far as I can see. The driver attaches to every >> > interface and creates ttyUSBx devices for these, without considering the >> > actual protocol used by the interfaces: >> >> <snip> >> >> Dan, you submitted this patch, is it not really needed? > > When the 'mbm' driver is accepted upstream, the option.c patch is no > longer required, and the VID/PID can be dropped from option.c. I fail to see the advantage of adding the VID/PID to option.c even without mbm. The device provides three classes of interfaces: cdc-acm, cdc-wdm and mbm. None of these are handled by the option driver AFAICS (please correct me if I'm wrong). The cdc-acm and cdc-wdm interfaces are quite useful even without mbm. They are sufficient for using both the GPS and the 3G modem (although probably at lower speed than the mbm driver would allow). But why prevent this device from being used just because one of the interface classes isn't supported by a driver yet? I fail to see the upside. Please educate me. Yes, the workaroud of blacklisting the option driver is simple. But then again: Why should this be needed? Bjørn -- Let me tell you something, you whimpering scumbag, life is rotten spelling -- 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
