Dan Williams <dcbw@xxxxxxxxxx> writes: > On Mon, 2016-02-22 at 18:03 +0700, Lars Melin wrote: >> On 2016-02-21 10:09, Daniel Johnson wrote: >> > On Fri, Feb 19, 2016 at 12:27 AM, Bjørn Mork <bjorn@xxxxxxx> wrote: >> > > One of them is likely a QCDM port if this is really a Qualcomm >> > > based >> > > device. The other might be an inactive NMEA port. Serial >> > > doesn't >> > > necessarily imply AT commands... >> > >> > I found the FCC ID for the device. >> > QISME206V-561 >> > >> > Searching for this at the FCC website revealed internal photos. >> > Looks >> > like it's Intel based. The significant non intel parts seem to be >> > DRAM, and a radio amplifier. >> > https://www.fcc.gov/general/fcc-id-search-page >> > -- >> > 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 >> > >> >> The serial interfaces should be handled by the option serial driver >> which btw already has support for it. >> >> qcserial will fight with option for ownership of the interfaces so >> the >> currently defined DEVICE_HWI(0x03f0, 0x581d) should be taken out of >> qcserial. Bjorn? > > If it's an Intel device, which it certainly looks like from the FCC > photos, then it should not be in qcserial at all. The Windows driver > config and the usb-devices dumps indicate that instead of the normal > Intel cdc-acm/mbim configuration that this device uses a Huawei- > specific layout like their Qualcomm-based devices. So this device > should probably go into 'option' for Cfg#1 (Jungo) and Cfg#2 > (cdc_ether) and it'll certainly need locking on specific > Class/SubClass/Protocol to ensure that option only claims the serial > interfaces and not the ethernet/ncm ones. Agreed. The DEVICE_HWI stuff in qcserial got a bit messy. There are either too many or too few high speed serial drivers based on usb_wwan :) But I guess the rule should be: Does it speak QCDM on any of the serial ports, then it goes in qcserial. Anything else goes in option. Does that match the original qcserial intention? Regarding the entries in option: It is unfortunate that HP (and other laptop vendors) insist on using their own vendor IDs for vendor specifc OEM products like these mdoem. The Huawei vendor matching in option works very well, but when the modules are programmed with a HP ID, then we are back to adding entries per device ID. Which is a game we cannot win wrt rarely seen laptop accessories. How many Linux users will care about the average HP LTE modem? My bet is less than one. What do you think are the chances that HP will be stupid enough to ever create a USB device with a ff/05/xx interface which is *not* a Huawei modem? How about just duplicating every Huawei ff/05/xx entry in option with the HP vendor ID? Seems less error prone than the alternatives to me. Bjørn -- 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
