On Thu, Apr 03, 2014 at 10:03:10AM +0200, Bjørn Mork wrote: > Rafał Miłecki <zajec5@xxxxxxxxx> writes: > > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 0 > > bNumEndpoints 0 > > bInterfaceClass 255 Vendor Specific Class > > bInterfaceSubClass 255 Vendor Specific Subclass > > bInterfaceProtocol 255 Vendor Specific Protocol > > iInterface 0 > > ** UNRECOGNIZED: 05 24 00 10 01 > > ** UNRECOGNIZED: 05 24 15 00 01 > > ** UNRECOGNIZED: 05 24 06 00 00 > > ** UNRECOGNIZED: 15 24 12 20 01 98 b0 6a 49 b0 9e 48 96 94 46 d9 9a 28 ca 4e 5d > > ** UNRECOGNIZED: 06 24 13 00 01 10 > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 1 > > bNumEndpoints 2 > > bInterfaceClass 255 Vendor Specific Class > > bInterfaceSubClass 255 Vendor Specific Subclass > > bInterfaceProtocol 255 Vendor Specific Protocol > > iInterface 0 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x81 EP 1 IN > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0200 1x 512 bytes > > bInterval 32 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x01 EP 1 OUT > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0200 1x 512 bytes > > bInterval 32 > > > > > Hmm, AFAICS we never change altsettings in the option/usb_wwan/ > usb-serial probing, so this function ends up without any endpoints at all. > As such it should just have failed the probe. But the option driver has > a static num_ports = 1, which looks like it is overriding the endpoint > based calculation in usb_serial_probe() even for the case where > num_bulk_out == 0. That cannot be right... You're right. We should probably require both bulk in and out endpoints in usb_wwan port_probe or return -ENODEV. The (original option) driver was apparently written under the assumption that either endpoint could be missing. It would handle opening a device without bulk-in (but would blow up during resume which was likely implemented later), but not a missing bulk-out in write() (although it is handled in some places). But since it also got the missing-end-point test wrong, this was never a (critical) issue... > I believe we should both change altsettings and fail if there still > aren't enough endpoints available. The option driver currently does not implement changing altsettings for any device as you noted. And in fact, this wouldn't even be necessary for all 19d2:0031. A quick search for lsusb -v output reveals that not all devices have these altsettings. As we haven't heard of this issue before, my guess is that the device in question is the odd one. Would only using interface 3 be sufficient for now? I'd assume so as this is reported as a regression (which triggers the oops, but the first two interfaces can obviously never have been used for anything). I'll cook up a patch for the end-point test during port_probe. Thanks, Johan -- 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
