Bjørn Mork <bjorn@xxxxxxx> [2015-11-04 16:57:06]: > > +#define QUECTEL_EC20_VENDORID 0x05c6 > > +#define QUECTEL_EC20_PRODUCTID 0x9215 > > +#define QUECTEL_EC20_NINTERFACES 5 > > +#define QUECTEL_EC20_QMI_IFACE_FIX 4 > > Not directly related to the issue at hand, but I sort of hate macros > like that. They provide little or no value, and make it much more > difficult to see what is going on. Yep, but magic number constants are worse. I don't know about better alternative. > In particular, if you went this route then you would probably want to define > > #define ACER_GOBI2K_VENDORID 0x05c6 > #define ACER_GOBI2K_PRODUCTID 0x9215 > #define ACER_GOBI2K_NINTERFACES 4 > #define ACER_GOBI2K_QMI_IFACE_FIX 0 > > to make this complete. And noone would notice that > ACER_GOBI2K_PRODUCTID and QUECTEL_EC20_PRODUCTID are the same value. > > In fact, the QUECTEL_EC20_VENDORID is really a Qualcomm device ID. > That's confusing already. Please use literals instead. So this means, that I should check for both cases? It's very unlikely, that someone would own both devices - does the Acer device even exist? > > + le16_to_cpu(dev->descriptor.idVendor) == QUECTEL_EC20_VENDORID && > > + le16_to_cpu(dev->descriptor.idProduct) == QUECTEL_EC20_PRODUCTID && > > Not that performance matters, but you can make these compile time > operations on BE by doing > > dev->descriptor.idVendor == cpu_to_le16(QUECTEL_EC20_VENDORID) && > dev->descriptor.idProduct == cpu_to_le16(QUECTEL_EC20_PRODUCTID) && > > instead. It's just a copy&paste from other sources, but thanks for the note. > I didn't think if that possibiity. Does it work? Yes it works, but in both alternatives it's still probing the interface 0 so I'll need to add rejecting of probing on it. usb 2-1.2: new high-speed USB device number 3 using ci_hdrc qmi_wwan: probe of 2-1.2:1.0 failed with error -22 qcserial 2-1.2:1.0: Qualcomm USB modem converter detected usb 2-1.2: Qualcomm USB modem converter now attached to ttyUSB0 ...snip... qmi_wwan 2-1.2:1.4: cdc-wdm0: USB WDM device qmi_wwan 2-1.2:1.4 wwan0: register 'qmi_wwan' at usb-ci_hdrc.1-1.2, WWAN/QMI device, 76:81:57:21:bb:4f > But modifying the match table like this is a little hacky in any case, I > guess. I know we do it for the dynamic part of the table, but that's > because there is no other way making dynamic device IDs work in > combination with the usbnet driver_info. Quirk is a hack in other words, isn't it? Anyway, what did you meant by a 'quirk' exactly in your 1st email reply, what would be a correct way of doing it? > Better to go for the first alternative with a double entry in the match > table. But it will need code to reject interface #0 on the Quectel > EC20, so qcserial can handle it. So this basically means merging both alternatives, but in the probe just quit the probing instead of modifying the match table, right? Thanks. -- ynezz -- 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
