Re: [PATCH 3/11] USB: interface PM state

On Friday 06 April 2007 8:08 am, Alan Stern wrote:
> On Thu, 5 Apr 2007, David Brownell wrote:
> 
> > On Thursday 05 April 2007 1:04 pm, Alan Stern wrote:
> > > This patch (as880) strives to keep the PM core's idea of a USB
> > > interface's power state in synch with usbcore's own idea.  In the end
> > > this doesn't really matter, but it's better to be consistent.
> > 
> > ISTR trying this originally and watching it break things in some
> > of the test scenarios I tried.  Quite a surprise actually.  And as
> > I recall, it interacted with the issue in your patch #7/11 ...
> 
> Did you run all those tests before usb_suspend_both() and
> usb_resume_both() were written?  If you did, these things work very
> differently now.

Yes, before.

I think the key thing to abstract from your comments below is that
this state was once used, but that's (thankfully) changed.

In fact, the generalization is that since dev.power.power_state is
going to be removed (this summer!), we want to know sooner -- rather
than later! -- if we even care about it.


> > I think that USB_SUSPEND was the key factor I saw, or remote wakeup.
> 
> Such testing is no longer necessary, or no longer _as_ necessary as
> before.  The value of intf->dev.power.power_state is not read anywhere in
> usbcore, only written.

Yeah, back then it wasn't as clear that power_state is conceptually
broken.


> (There is an apparently unnecessary reference in 
> usbtest.c, but it shouldn't be affected by this patch.  It also has a
> race...)

Presumably autoresume handles that issue now.

 
> BTW, the same is true for udev->dev.power.power_state, with two 
> exceptions:
> 
> 	At one point in hub.c the value is checked in lieu of looking
> 	at udev->state when CONFIG_USB_SUSPEND isn't set;
> 
> 	At one place in hcd-pci.c the value for a root hub is checked --
> 	this really should be replaced with a check for USB_STATE_SUSPENDED.

Again, power_state clearly being on the way out, we have alternate
solutions for what it previously seemed to solve.


> So the only possible impact would lie in the PM core.  There the only uses 
> are to control whether certain messages are logged and to control whether 
> or not the suspend and resume methods actually get called.  Since the 
> suspend and resume methods for USB interfaces don't do anything, again 
> this won't matter.
> 
> (There also are some uses in runtime.c, but that whole piece of code is 
> fundamentally broken anyway.)

Yeah, that's why it's all deprecated.  And likely gone in 2.6.23 ...

- Dave


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel