Hi All, I am seeing a peculiar behaviour which I think *might* be caused by usb_new_device(). Since usb_new_device() is one of the core APIs, I cannot explain how PM works for USB device at later point in time. In a particular use-case, our composite USB device exposes HID interface with vendor report descriptor. Since the standard HID-class driver's HID-input part is unable to decode this vendor report descriptor, it is unable to bind itself to this interface. After this, we don't see any L2 requests on USB bus analyser. Obvious reason seems to be, since no driver is bound to interface, there cannot be PM call-backs since driver has these call-backs. But I am expecting that the USB device (which is parent of HID interface) should see L2. The reason being, USB-core seems to properly do runtime get/put wherever needed. And HID interface has no driver, so from USB-core point of view, it is a USB device w/o any interface. (please correct if this is incorrect expectation). With that said, I am confused about usb_new_device() in this context. It seems to call usb_disable_autosuspend() ==> pm_runtime_forbid() ==> increment usage_count. However, it never calls usb_enable_autosuspend() itself. Now since USB PM (and L2) works fine at later point in time (i.e.: after all the interfaces are bound to their appropriate drivers), I think somewhere the equivalent of usb_enable_autosuspend() gets called for the USB device and hence USB PM works fine. I wonder this *may be* be an issue I am seeing with the use-case mentioned above. But definitely confused about it and hence thought of sending this email. Does this description makes sense? Is it necessary to call usb_enable_autosuspend() in usb_new_device()? Thanks,
