Michal Malý <madcatxster@xxxxxxxxx> writes:
> On Monday 30 of September 2013 12:19:41 you wrote:
>> Michal Malý <madcatxster@xxxxxxxxx> writes:
>> > my Huawei 3G modem has an embedded Smart Card reader which causes
>> > trouble when the modem is being detected (a bunch of "<warn>
>> > (ttyUSBx): open blocked by driver for more than 7 seconds!" in
>> > messages.log). This trivial patch corrects the problem for me. The
>> > modem identifies itself as "12d1:1406 Huawei Technologies Co.,
>> > Ltd. E1750" in lsusb although the description on the body says "Model
>> > E173u-1"
>>
>> This is surprising because the first thing option_probe() does is:
>>
>> /* Never bind to the CD-Rom emulation interface */
>> if (iface_desc->bInterfaceClass == 0x08)
>> return -ENODEV;
>>
>>
>> so it shouldn't ever bind to any storage functions. Unless it is a
>> vendor specific storage function, of course...
>>
>> > + { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
> HUAWEI_PRODUCT_E1750,
>> > 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t)
>> > &net_intf2_blacklist },
>>
>> Does this mean that intf #2 is actually a storage function using
>> ff/ff/ff class codes?
>>
>>
>> Bjørn
>
> The device has 4 interfaces. IF 0 and IF 1 are used to talk to the modem, IF 3
> is a micro SD card reader and IF 2 is a mysterious interface. According to
> Windows .INF the "USB\VID_12d1&PID_1406&MI_02" device is a "HUAWEI Mobile
> Connect - USB Smart Card Reader"; whatever that means. The SD card reader has
> 0x08 interface class and it seems to be picked up correctly.
Yes, that's what I thought. So intf #2 probably doesn't have anything
to do with the SD reader?
> IF 2 info from lsusb:
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 255 Vendor Specific Subclass
> bInterfaceProtocol 255 Vendor Specific Protocol
> iInterface 0
> ** UNRECOGNIZED: 36 21 00 01 00 07 00 00 03 00 00 00 a0 0f 00 00 a0 0f
> 00 00 00 00 00 00 00 2a 00 00 16 40 05 00 00 00 00 00 fe 00 00 00 00 00 00 00
> 00 00 00 00 30 02 01 00 0f 01
Right. Based on the length and ID of this class descriptor, I am pretty
sure this is a CCID interface descriptor, except that the class codes
are wrong. You could hack up a copy of lsusb to decode the vendor
specific class as if it was USB_CLASS_CCID and have this additional
descriptor nicely decoded into CCID properties.
I believe some modems provide a CCID interface to the SIM. Could this
be such a device?
In any case, I guess the patch is necessary. This interface should be
blacklisted as it's not a serial interface. CCID support is done in
userspace. Thanks a lot for providing the additional info.
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
