On Thu, 2016-02-25 at 18:15 +0100, Bjørn Mork wrote: > 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.h > > > > tml > > > > > > > > > > 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? No. There are plenty of things that speak QCDM that are driven by 'option' or 'qcaux'. The original intention of qcserial was to facilitate the firmware download with gobi_loader that is more or less obsolete these days, since the Gobi devices usually carry their own firmware onboard. But G1K, G2K, and G3K devices still require the loader. If devices don't need the loader, or their firmware can be upgraded through that special QMI mode then great, they don't need qcserial. Or if we figure out how to support whatever special magic snowflake-ness qcserial does in option, great. > 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. That makes me both concerned (because I think the chance of this is non-zero) and sad (for the same reason). For now I think we should just add the few specific class/subclass/protocol lines for this modem for the specific HP USB IDs. I'm not sure there's any way around this. Dan -- 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
