From: Christof Meerwald <cme...@cmeerw.org>, Date: Sat, 4 Apr 2015 11:55:35 +0200
> On Sat, Apr 04, 2015 at 04:15:40PM +0900, Ryo ONODERA wrote: >> From: Christof Meerwald <cme...@cmeerw.org>, Date: Sat, 4 Apr 2015 08:42:23 >> +0200 >> > On Sat, Apr 04, 2015 at 08:50:01AM +0900, Ryo ONODERA wrote: >> >> Please remove cdce(4) and umodem(4) entries from your kernel configuration >> >> file (your device should be recognized as ugen(4)) and run >> >> $ gcc -o probe_usb probe_usb.c >> >> # ./probe_usb /dev/ugen0.00 >> > >> > # ./probe_usb /dev/ugen0.00 >> > length: 9 >> > descriptor type: 2 >> > total length: 2147470578 >> > num interface: 2 >> > config value: 2 >> > configuration: 0 >> > Attributes: (0xc0) Self powered >> > max power: 500 mA >> > >> > Interface 0: >> > Length: 9 >> > Descriptor Type: 4 >> > Interface No: 0 >> > Alt Setting: 0 >> > Num Endpoints: 1 >> > Interface Class: 2 >> > Interface SubClass: 2 >> Your cdce(4) has Interface Class Subclass = 2. >> According to table 16 of >> http://cscott.net/usb_dev/data/devclass/usbcdc11.pdf >> Universal Serial Bus Class Definitions for Communication Devices Version 1.1, >> 02h is assigned to Abstract Control Model. >> As far as I understand correctly, Abstract Control Model is used for >> RS-232C emulation devices, for example USB modem. > > I don't think that's actually causing the problem - if you look in > umodem.c it checks for > > if (uaa->class != UICLASS_CDC || > uaa->subclass != UISUBCLASS_ABSTRACT_CONTROL_MODEL || > !(uaa->proto == UIPROTO_CDC_NOCLASS || uaa->proto == UIPROTO_CDC_AT)) > return (UMATCH_NONE); > > and the proto is 255 in my case and that causes it to return > UMATCH_NONE > >> > Interface 1: >> > Length: 9 >> > Descriptor Type: 4 >> > Interface No: 1 >> > Alt Setting: 0 >> > Num Endpoints: 2 >> > Interface Class: 10 >> > Interface SubClass: 0 >> > Interface Protocol: 0 > > I think that's actually the one that causes the problem in r1.66 of > umodem.c > > id = usbd_get_interface_descriptor(uaa->iface); > if (uaa->subclass != UISUBCLASS_ABSTRACT_CONTROL_MODEL && > (id->bInterfaceClass == UICLASS_CDC_DATA && > id->bInterfaceSubClass == UISUBCLASS_DATA)) > return (UMATCH_IFACECLASS_IFACESUBCLASS); > > Now I have to say that I don't have much understanding of the NetBSD > code base or USB, but this is my understanding: > > Looking at usbd_attachinterfaces uiaa (which I think is then uaa in > umodem.c) gets populated as: > > uiaa.iface = ifaces[i]; > uiaa.class = ifaces[i]->idesc->bInterfaceClass; > uiaa.subclass = ifaces[i]->idesc->bInterfaceSubClass; > > usbd_get_interface_descriptor(uaa->iface) just returns uaa->iface->idesc > > I would therefore always expect id->bInterfaceClass == uaa->class and > id->bInterfaceSubClass == uaa->subclass and the above 'if' could then > be rewritten as: > > if (uaa->class == UICLASS_CDC_DATA && > uaa->subclass == UISUBCLASS_DATA) > return (UMATCH_IFACECLASS_IFACESUBCLASS); > > which clearly looks wrong to me. > > > I could of course be wrong here, but I don't see how uaa->subclass can > be different from id->bInterfaceSubClass in that code. I see. It may be wrong. Sadly I am not kernel developer and I cannot answer your question... By the way I have cdce(4) device and it works fine for me. cdce0 at uhub1 port 2 configuration 2 interface 0 cdce0: Realtek USB 10/100 LAN, rev 2.10/20.00, addr 6 $ sudo usbdevs -a 6 -v Controller /dev/usb0: addr 6: high speed, power 100 mA, config 2, USB 10/100 LAN(0x8152), Realtek(0x0bda), rev 20.00, serial XX...XX My machine is busy now and I will post the output of probe_usb later. -- Ryo ONODERA // ryo...@yk.rim.or.jp PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3