Not many comments here, so I guess you are all waiting for me to go away
:-)
In the mean time I can share one issue I don't yet have a final solution
for, but there are a couple of possible ones below:
- "needs_remote_wakeup" is a per-interface flag which cdc-wdm assume it
can set on open and clear on release. This may result in cdc-wdm
clearing the flag when the main driver wants it set, which won't work
very well...
This does not matter for the device I'm testing as it does not support
remote wakeup, but the issue does of course need to be dealt with
nevertheless.
A simple solution, which does not require any changes to cdc-wdm, is
making the main driver not depend on remote wakeup. This means
disabling autosuspend while the main driver may need the device, from
open until close. I.e for a usbnet driver: while the netdevice is up.
But if we want the main driver to support autosuspending an active
device by using remote wakeup, then we need to add some support to
cdc-wdm for sharing the flag. One simple way would be to add a counter
and an interface function to be used by the main driver when it wants
the flag set/cleared. Something like (but with locking added...):
int usb_cdc_wdm_remote_wakeup(struct usb_interface *intf, bool on)
{
struct wdm_device *desc = wdm_find_device(intf);
if (on) {
if (!desc->remote_wakeup++)
intf->needs_remote_wakeup = 1;
} else {
if (!--desc->remote_wakeup)
intf->needs_remote_wakeup = 0;
}
return desc->remote_wakeup;
}
What do you think? Just document that any driver which uses cdc-wdm as
a subdriver cannot make use of remote wakeup for now? Or add some
interface like the above? Or something else?
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
