After some investigation I found this in option.c:
/* ZTE PRODUCTS -- alternate vendor ID */
#define ZTE_VENDOR_ID2 0x1d6b
#define ZTE_PRODUCT_MF_330 0x0002
..
{ USB_DEVICE(ZTE_VENDOR_ID2, ZTE_PRODUCT_MF_330) },
But this matches... "Linux Foundation 2.0 root hub",
which has this module alias:
usb:v1D6Bp0002d0206dc09dsc00dp00ic09isc00ip00
What are options to fix this option now? :)
Thanks!
[Cc'ing linux-kernel due to interesting USB ID clash]
/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Forgot to mention, and to add proper Cc. The commit
is this one:
commit a559d2c8c1bf652ea2d0ecd6ab4a250fcdb37db8
Author: Dominik Brodowski <li...@dominikbrodowski.net>
Date: Wed Apr 14 21:36:42 2010 +0200
USB: option: add ID for ZTE MF 330
Based on the information provided for by Paweł Drobek, add
a second vendor ID and the correct product ID for ZTE MF 330.
Reported-by: Paweł Drobek <pawel....@gmail.com>
Signed-off: Dominik Brodowski <li...@dominikbrodowski.net>
Signed-off-by: Greg Kroah-Hartman <gre...@suse.de>
Are the IDs really correct? Maybe it's just a typo
after all...
It is interesting that no one noticed this so far.
Or it's just because it's difficult to search for -
"option" is really a bad search term ;)
I don't know, Paweł, can you provide the output of 'lsusb -v' for your
system where you saw this being a option device instead of a hub?
thanks,
greg k-h
Can you please provide the information Greg asked?
> I don't know, Paweł, can you provide the output of 'lsusb -v' for your
> system where you saw this being a option device instead of a hub?
Namely, `lsusb -v' output from the system when this
modem is inserted.
At least, maybe this device ID should be restricted to
the particular class of devices. Alternatively, if number
of such devices on the marked is small (google wasn't able
to find any other references), it should be easy to control
it using a custom udev rule that loads `option' driver and
forcibly binds it to this device. That is, by the way, an
alternative solution to make it work.
But it is curious that ZTE used "wrong" vendor class for
its product.
Thanks!
/mjt
Which PCMCIA card? The device at question is USB, not PCMCIA,
that's why we requested lsusb.
Has anyone else seen this device? For some reason I doubt
it has the indicated USB ID...
Thanks,
So, what's our course of actions now?
I'd suggest to revert this change and deal with this device
again (specifying the device IDs more precisely, like,
including the device class or what it is called in USB
world) when someone will have it for real.
Paweł, are there any news on this?
Thanks,
/mjt
> 2011/5/27 Michael Tokarev <m...@tls.msk.ru <mailto:m...@tls.msk.ru>>
>
> 27.05.2011 14:02, Greg KH wrote:
> > On Fri, May 27, 2011 at 11:06:37AM +0200, Paweł Drobek wrote:
> >> dunno, zte mf330 is pcmcia card identified itself as usb device
> which need to
> >> get working pcmcia options from kernel.
> >
> > Yes, older devices put a whole USB host controller device on the
> PCMCIA
> > card in order to talk to it properly without having to change their
> > hardware design of the modem chip.
>
> So, what's our course of actions now?
>
> I'd suggest to revert this change and deal with this device
> again (specifying the device IDs more precisely, like,
> including the device class or what it is called in USB
> world) when someone will have it for real.
>
> Thanks,
>
> /mjt
>
>
>
>
> --
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GCS d+ s:+ a- C++ UL++++ P L+++ !E W+++ N++ o+ K- w++
> !O M V- PS+ PE+ Y PGP++ !t !5 X++++ R+ tv- b++ DI++ D++
> G++ e+++ h+ r-- y
> ------END GEEK CODE BLOCK------
Hi guys
In attachment is a file with "lsusb -v" output, please check it. if you
need something more feel free to tell me about it
Best regards Pawel
> Bus 003 Device 002: ID 19d2:0001 ONDA Communication S.p.A.
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x19d2 ONDA Communication S.p.A.
> idProduct 0x0001
> bcdDevice 0.00
> iManufacturer 1 Qualcomm, Incorporated
> iProduct 2 ZTE CDMA Technologies MSM
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 85
> bNumInterfaces 3
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xa0
> (Bus Powered)
> Remote Wakeup
> MaxPower 500mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 255 Vendor Specific Subclass
> bInterfaceProtocol 255 Vendor Specific Protocol
> iInterface 3 Data Interface
So, as far as I can see, this is covered by
#define ZTE_VENDOR_ID 0x19d2
#define ZTE_PRODUCT_MF622 0x0001
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF622, 0xff, 0xff, 0xff) }, /* ZTE WCDMA products */
and it should Just Work aftere reverting a559d2c8c1bf652ea2d0ecd6ab4a250fcdb37db8
"USB: option: add ID for ZTE MF 330". But I'm not sure this really
is MF330, since the device ID says it's MF622.
Are we talking about the same device?
Besides, why in linux it's identified as ZTE, while
lsusb lists it as "ONDA Comm." ?
Thanks,
/mjt
ONDA and ZTE are usually the very same chip.
Also please note that USB ID of these devices usually changes after
'usb_modeswtich' triggers in userspace (and many distros ship udev rule
for this as a default nowadays), which might contribute to the overall
confusion a little bit more.
--
Jiri Kosina
SUSE Labs