On Sun, Jun 10, 2012 at 7:13 PM, Huajun Li <huajun.li.lee@xxxxxxxxx> wrote: > On Sun, Jun 10, 2012 at 5:53 PM, Ming Lei <tom.leiming@xxxxxxxxx> wrote: >> On Sun, Jun 10, 2012 at 9:07 AM, Huajun Li <huajun.li.lee@xxxxxxxxx> wrote: >> >>> >>> However, the other interface can work, it is of "bInterfaceClass >>> 10 CDC Data". I can set IP to usb0 and it work fine. >>> >>> BTW, the device has 2 interfaces, one is of "bInterfaceClass 10 >>> CDC Data" which includes bulk in/out endpoint for rx/tx; the other is >>> "bInterfaceClass 2 Communications" which contains the >>> interrupt endpoint. From info dumped by "lsusb -v", the device is >>> compliance with CDC protocol. >> >> Both the two interfaces belongs to cdc_ether device, see cdc spec >> and usbnet_generic_cdc_bind(), which will make cdc_ether dirver to >> claim data interface. >> > > Yes, you are right. > >>> >>>>>> BTW, the device can work well if I modprobe cdc_ether driver after >>>>>> changed the configuration. >>>> >>>> Maybe just the delay introduced by 'modprobe cdc_ether' fixes the >>>> problem. >> >> If you can change the firmware, please find the bug and fix it. Otherwise, >> you can add a simple quirk in cdc_ether.c for your device. >> > Yes, this solution can solve the issue directly. > > However, besides "-EPIPE", I think usbnet.c should also handle the > error of "-EPROTO". Yes, you can clear halt for -EPIPE, and take Alan's suggestion to reset device if the error of "-EPROTO" is got. Thanks, -- Ming Lei -- 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
