On Thu, 2019-08-01 at 13:51 -0400, Alan Stern wrote: > On Thu, 1 Aug 2019, Mayuresh Kulkarni wrote: > > > > > 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. > There are other possible reasons. For example, what is the setting > stored in /sys/bus/usb/devices/.../power/control (fill in the "..." > with the appropriate name for your device)? > > If the file contains "on" then runtime PM is forbidden and the device > will always remain at full power. If the file contains "auto" then > the > device will be subject to normal runtime-PM suspends and resumes. > Hi Alan, Thanks a lot for clearing out the confusion. Our USB device can operate in 2 mutually exclusive modes: one is normal composite USB audio mode and other is vendor specific HID device mode. On the same platform (Android based): - When the device is in normal composite USB audio mode, "cat /sys/bus/usb/devices/.../power/control" show "auto". - When the device is in vendor specific HID device mode, "cat /sys/bus/usb/devices/.../power/control" show "on". And hence as per your comment, I am unable to see USB-2.0 L2 for vendor specific HID device mode. I guess I need to find out "who" is setting the /power/control = "auto" when composite USB audio device is detected. And explore if it could be moved to a more generic place. Is there any module parameter (or some other means) by which, power/control (or deprecated power/level) will always be "auto", by default? > > > > 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). > More accurately, it is a USB device with one interface which is not > bound to a driver. > > > > > 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. > Correct. By default, all USB devices except hubs are forbidden to go > into runtime suspend. This setting can be changed by userspace (by > writing to the sysfs file mentioned above). > > > > > 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. > There are programs, like powertop, which will automatically write > "auto" to the power/control sysfs file when a new device appears. > Doing so calls pm_runtime_allow(), which decrements usage_count. > Cool, thanks for this info. > > > > 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()? > It is not necessary. Check that sysfs file and see what it > contains. > In fact, you can check the contents of all the files in the device's > sysfs power/ subdirectory. Thanks, the files under power/ have useful info (great for doing diagnosis). > > Alan Stern >
