linux-kernel - Re: [RFC][PATCH 2/2] PM: Make system-wide PM and runtime PM handle subsystems consistently

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1102161710090.1626-100000@iolanthe.rowland.org>
Date:	Wed, 16 Feb 2011 17:23:09 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kevin Hilman <khilman@...com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Greg KH <greg@...ah.com>, LKML <linux-kernel@...r.kernel.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Len Brown <lenb@...nel.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: [RFC][PATCH 2/2] PM: Make system-wide PM and runtime PM handle
 subsystems consistently

On Wed, 16 Feb 2011, Rafael J. Wysocki wrote:

> On Wednesday, February 16, 2011, Alan Stern wrote:
> > On Wed, 16 Feb 2011, Rafael J. Wysocki wrote:
> > 
> > > Unfortunately, it doesn't work on my Acer Ferrari One.  The problem is that
> > > hcd_pci_suspend() fails for the EHCI controller, apparently because the root
> > > hub is not suspended.  Do root hubs need both class suspend and bus type
> > > suspend to work at the same time?
> > 
> > No, only the bus type suspend method is needed.
> 
> Bus type or device type?  It appears to be the latter from reading the code
> (although admittedly not too thorough).

You're right.  I forgot about how the PM methods were split up.  :-(

> > Can you provide the dmesg log using a kernel built with CONFIG_USB_DEBUG?
> 
> Well, I know what the problem is.
> 
> USB defines usb_device_type pointing to usb_device_pm_ops that provides
> system-wide PM callbacks only and usb_bus_type pointing to
> usb_bus_pm_ops that provides runtime PM callbacks only.  So it looks like
> we should move either the system-wide PM callbacks to usb_bus_pm_ops,
> or the runtime PM callbacks to usb_device_pm_ops.

Yes.  IIRC, I did it that way so that the runtime PM routines could be 
static.  Making them non-static isn't a big deal, though.

> FWIW, the appended patch helps on my test machine, but I'm not sure if it
> is the right thing to do.

It is.  Except that the inline stubs aren't needed for anything; they 
don't have to be added to usb.h.

> Apart from this I think the order of checks introduced by the $subject patch
> should be:
> (1) If dev->class != NULL and dev->class->pm != NULL, use dev->class,
>     or otherwise
> (2) if dev->type != NULL and dev->type->pm != NULL, use dev->type,
>     or otherwise
> (3) use dev->bus (if present).
> as that would allow classes and device types to override bus type PM
> callbacks if they wish to.

I haven't heard of any device types being present on more than one kind
of bus, so it makes sense for device types to override bus types.  But
I'm not so sure about the priority we should give to classes.  On the
other hand, if no classes define a dev_pm_ops then of course it doesn't
matter.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/