autosuspend and devices without remote wakeup support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm desperately trying to understand exactly what successful autosuspend
depends on. It seems to me that a common model (observed in cdc_ether
and cdc_wdm at least) is

- set "needs_remote_wakeup = 1" on open and "needs_remote_wakeup = 0" on
  close.
- use pairs of usb_autopm_get_interface/usb_autopm_put_interface around
  any device access

This works well if the device supports remote wakeup, but when it
doesn't then this ends up with a device that only rarely autosuspends.
It is of course expected that the device cannot autosuspend between the
open and close calls, as needs_remote_wakeup is 1 then.  But after close
I would expect the device to autosuspend again.  It does not. Until some
external trigger event happens (e.g. changing the autosuspend timeout).

I wonder if the problem might be that the usbcore doesn't notice the
changed needs_remote_wakeup?  I experimented with wrapping this change
between usb_autopm_get_interface and usb_autopm_put_interface and that
worked!  I.e.

		status = usb_autopm_get_interface(desc->intf);
		desc->intf->needs_remote_wakeup = 0;
		if (!status)
			usb_autopm_put_interface(desc->intf);


causes the device to start autosuspending, while merely doing

		desc->intf->needs_remote_wakeup = 0;

does not.

Any comments?  Am I totally lost, or should drivers which modify
needs_remote_wakeup always wrap the change in usb_autopm_get_interface/
usb_autopm_put_interface to ensure that the change is noticed?


Bjørn
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux