Re: About usb_new_device() API

[Mayuresh Kulkarni <mkulkarni@opensource.cirrus.com>]

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
>