[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160305115842.GB11846@gmail.com>
Date: Sat, 5 Mar 2016 12:58:42 +0100
From: Ingo Molnar <mingo@...nel.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Steve Muckle <steve.muckle@...aro.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux PM list <linux-pm@...r.kernel.org>,
Juri Lelli <juri.lelli@....com>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Viresh Kumar <viresh.kumar@...aro.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Michael Turquette <mturquette@...libre.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching
* Rafael J. Wysocki <rafael@...nel.org> wrote:
> > Honestly I wonder if it's better to just try the "no notifiers with fast
> > drivers" approach to start. The notifiers could always be added if platform
> > owners complain that they absolutely require them.
>
> Well, I'm not sure what happens if we start to fail notifier registrations. It
> may not be a well tested error code path. :-)
Yeah, so as a general principle 'struct notifier_block' as a really bad interface
with poor and fragile semantics, and we are trying to get rid of them everywhere
from core kernel code. For example Thomas Gleixner et al is working on eliminating
them from the CPU hotplug code - which will get rid of most remaining notifier
uses from the scheduler as well.
So please add explicit cpufreq driver callback functions instead, which can be
filled in by a platform if needed. No notifiers!
Thanks,
Ingo
Powered by blists - more mailing lists