linux-kernel - Re: [RFC/PATCH] platform_bus: allow custom extensions to system PM methods

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] [day] [month] [year] [list]

Date:	Thu, 18 Mar 2010 10:20:24 -0700
From:	Greg KH <gregkh@...e.de>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	Magnus Damm <damm@...nsource.se>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Dmitry Torokhov <dtor@...l.ru>,
	Eric Miao <eric.y.miao@...il.com>
Subject: Re: [RFC/PATCH] platform_bus: allow custom extensions to system PM
 methods

On Thu, Mar 18, 2010 at 09:57:06AM -0700, Kevin Hilman wrote:
> Greg KH <gregkh@...e.de> writes:
> 
> > On Wed, Mar 17, 2010 at 04:18:15PM -0700, Kevin Hilman wrote:
> >> When runtime PM for platform_bus was added, it allowed for platforms
> >> to customize the runtime PM methods since they are defined as weak
> >> symbols.
> >> 
> >> This patch allows platforms to also extend the system PM methods with
> >> custom hooks so runtime PM and system PM extensions can be managed
> >> together by custom platform-specific code.
> >
> > Wow, that's scary, I didn't realize that was done for the runtime stuff.
> >
> > What would you be replacing these functions with for your platform that
> > would require it to be in arch-specific code?
> 
> I'm basically copying the existing functions and extending them with
> platform-specific code to manage device clocks and other PM HW state.
> IOW, I still call the drivers PM methods, but also take care of some
> platform specific PM HW management.  This is just like the runtime PM
> hooks: platform-specific code + calling drivers runtime PM methods.
> 
> On my platform (TI OMAP), the code to handle device PM is common for
> all devices, so for runtime PM, I'm taking care of it at the bus
> level.  At the hardware level, there's really no difference between
> runtime and system PM, so I want to take advantage of the same
> platform specific code for system PM
> 
> Initially, rather than making the system PM methods themselves weak, I
> added some weak hooks that could be overridden instead (see test patch
> below).  The problem with that is that it is not as flexible if you
> want to run some custom code before and/or after calling the drivers
> PM methods.  To be more flexible, using this approach, we'd probably
> need pre- and post- hooks to be used before and after the driver's PM
> methods are called.  Rather than add all these hooks, I decided it was
> cleaner to just allow override of the primary methods themselves,
> which parallels the runtime PM approach.

Ok, that sounds reasonable for now.  I'll queue it up for .35.

thanks,

greg k-h
--
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/