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: <20100423150528.GB7648@suse.de>
Date:	Fri, 23 Apr 2010 08:05:28 -0700
From:	Greg KH <gregkh@...e.de>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Greg KH <greg@...ah.com>, "Rafael J. Wysocki" <rjw@...k.pl>,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org
Subject: Re: platform_bus: Allow runtime PM by default

On Fri, Apr 23, 2010 at 11:57:51AM +0100, Mark Brown wrote:
> On Thu, Apr 22, 2010 at 04:53:53PM -0700, Greg KH wrote:
> > On Fri, Mar 26, 2010 at 05:42:50PM +0000, Mark Brown wrote:
> 
> > > Change the default implementation to the standard pm_generic_runtime
> > > one, allowing drivers to use runtime PM without per-architecture
> > > changes.
> 
> > That's nice, but it breaks the build on my system:
> >   CC      drivers/base/platform.o
> > drivers/base/platform.c: In function ???platform_pm_runtime_suspend???:
> > drivers/base/platform.c:970: error: implicit declaration of function ???pm_generic_runtime_suspend???
> > drivers/base/platform.c: In function ???platform_pm_runtime_resume???:
> > drivers/base/platform.c:975: error: implicit declaration of function ???pm_generic_runtime_resume???
> > drivers/base/platform.c: In function ???platform_pm_runtime_idle???:
> > drivers/base/platform.c:980: error: implicit declaration of function ???pm_generic_runtime_idle???
> > make[1]: *** [drivers/base/platform.o] Error 1
> > make: *** [_module_drivers/base] Error 2
> 
> > Care to fix it up?
> 
> This depends on "PM: Provide generic subsystem-level callbacks" which is
> in Linus' tree - which kernel version are you building against and with
> what config?  Things work fine for me in -next...

I was using Linus's latest tree as of yesterday when this failed.  Are
you relying on something in -next that is not in Linus's tree?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ