Andiry Xu wrote:
+ break;
+ total_len -= length;
+
+ header += length;
+ cap = (struct usb_dev_cap_header *)header;
+ length = (int)le16_to_cpu(cap->bLength);
byte
+
+ if (le16_to_cpu(cap->bDescriptorType)
+ != USB_DT_DEVICE_CAPABILITY) {
also a byte
+ dev_warn(ddev, "descriptor type invalid, skip\n");
mind dumping the type that has been identified as invalid?
OK. But if this field is wrong, the value is meaningless. Can't imaging
a different type of descriptor is inserted to BOS descriptor set.
True. The user probably doesn't care at all. I guess the only person that
would be interested is the developer that is wondering why the host is
not accepting his BOS descriptor. So don't bother adding it.
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 90ae175..4ca6bb2 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3041,6 +3041,9 @@ hub_port_init (struct usb_hub *hub, struct usb_device *udev, int port1,
goto fail;
}
+ if (udev->wusb == 0 && udev->descriptor.bcdUSB >= 0x0210)
+ retval = usb_get_bos_descriptor(udev);
+
retval = 0;
so retval is overwritten
Yes, this patch will not check the retval, because BOS descriptor set
is an extensive descriptor and the failure should not prevent the device
from normal initialization. The retval will be used when the driver wants
to check certain capabilities from the BOS descriptor set.
Then please don't fetch the return value and let it being overwritten
later because it is a matter of time until someone "fixes" this.
Thanks,
Andiry
Sebastian
--
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
