linux-kernel - Re: [PATCH V2 1/2] cpufreq: suspend governors on system suspend/hibernate

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: <9179214.Tbesu8t5px@vostro.rjw.lan>
Date:	Tue, 26 Nov 2013 21:18:42 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Pavel Machek <pavel@....cz>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>,
	linaro-kernel@...ts.linaro.org, patches@...aro.org,
	cpufreq@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org, tianyu.lan@...el.com, nm@...com,
	jinchoi@...adcom.com, sebastian.capella@...aro.org
Subject: Re: [PATCH V2 1/2] cpufreq: suspend governors on system suspend/hibernate

On Tuesday, November 26, 2013 08:39:02 PM Pavel Machek wrote:
> Hi!
> 
> > This patch adds cpufreq callbacks to dpm_{suspend|resume}_noirq() for handling
> > suspend/resume of cpufreq governors. This is required for early suspend and late
> > resume of governors.
> > 
> > There are multiple problems that are fixed by this patch:
> > - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His board
> >   wasn't working well with suspend/resume as calls for removing non-boot CPUs
> >   was turning out into a call to drivers ->target() which then tries to play
> >   with regulators. But regulators and their I2C bus were already suspended and
> >   this resulted in a failure. This is why we need a PM notifier here.
> > - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
> >   tunables configuration for clusters/sockets with non-boot CPUs was getting
> >   lost after suspend/resume, as we were notifying governors with
> >   CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
> >   deallocating memory for tunables.
> > 
> > +/*
> > + * Callbacks for suspending/resuming governors as some platforms can't change
> > + * frequency after this point in suspend cycle. Because some of the devices
> > + * (like: i2c, regulators, etc) they use for changing frequency are suspended
> > + * quickly after this point.
> > + */
> > +void cpufreq_suspend(void)
> > +{
> > +	struct cpufreq_policy *policy;
> > +	unsigned long flags;
> > +
> > +	if (!has_target())
> > +		return;
> > +
> > +	pr_debug("%s: Suspending Governors\n", __func__);
> > +
> > +	list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
> > +		if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
> > +			pr_err("%s: Failed to stop governor for policy: %p\n",
> > +					__func__, policy);
> 
> So... we freeze frequencies in whatever state they are, yes?

Yes.  The idea was to do that after suspending devices in which case it wouldn't
matter so much.  But Viresh always has to complicate things.

> Should we go to some specific frequency?

If that is done where it is done, yes, we should.

Thanks,
Rafael

--
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/