Hi Oliver,

> > > this patch against vanilla 2.6.27-rc4 implements full autosuspend for
> > > btusb. It should allow the HCI to be suspended during periods of inactivity
> > > while retaining full service if the device supports USB remote wakeup.
> > 
> > actually we do have two cases. An inactive device can be woken up by an
> > HCI Connection Request coming via the interrupt endpoint or if we have a
> > send_frame callback via the Bluetooth stack itself.
> 
> Yes, if send_frame triggers it, we wake using a work queue. A connection
> request will wake us via remote wakeup.
> 
> > What do we do if a device does not support remote wakeup?
> 
> Autosuspend on close, resume on open. I don't think we can do more.

sounds good to me. I wanna split the whole work into small patches so we
can have an easier review. I attached the first two of this series and
they should apply cleanly against 2.6.27-rc4, but keep in mind that you
need the usb_unlink_anchored_urbs() patch too.

> > > Please test and/or comment on the code.
> > > It works for me with a few glitches but still needs to be a bit polished.
> > 
> > Please explain the tx_in_flight stuff to me. It looks unneeded since we
> > anchor all TX URBs anyway.
> 
> The completion of an URB may happen after the autosuspend timeout passed.
> But we cannot use the pm counters as they are not accessible in interrupt.
> Hence we must maintain a counter ourselves.

Can we not just check the number of URBs in the anchor? I am against
just duplicating a counter, but then lets call it it what it is to make
it gets not misused. It is a purely a PM counter.

> > So can we just leave the ISOC interface stuff out of it and try to get
> 
> The isoc stuff should be handled already, but I haven't tested that.

I know, but I wanna get the basic logic clean and tested. The SCO part
comes after that. Even if I think it should be good already.

> > the case right where we have control and interrupt URBs only and maybe
> > bulk URBs in case we an ACL link up.
> > 
> > This reminds me that we should extend the notify() callback to inform
> > about sniff and active state changes. Since in theory when a connection
> > goes into sniff mode, we could suspend it.
> 
> We should definitely do that.

I will work on a patch for that one.

Regards

Marcel