From: Borislav Petkov <bp@alien8.de>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, linaro-dev@lists.linaro.org,
robin.randhawa@arm.com, Steve.Bannister@arm.com,
Liviu.Dudau@arm.com
Subject: Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
Date: Tue, 5 Feb 2013 10:15:32 +0100 [thread overview]
Message-ID: <20130205091532.GA4827@pd.tnic> (raw)
In-Reply-To: <CAOh2x==fyfYwz+eXmPhBJTE+_q_fHyx2drXrM789XvCfEqPBUQ@mail.gmail.com>
On Tue, Feb 05, 2013 at 12:50:31PM +0530, Viresh Kumar wrote:
> > I think this is cleaner but whatever - I don't care that much. My
> > only strong concern is that this thing should be a Kconfig option and
> > optional for arches where it doesn't apply.
>
> Your concern is: we don't want to fix userspace for existing platforms
> where we have just a single cluster and so struct policy in the system.
No, as I said so many times already and you're unwilling to understand
it: multiple policies support in cpufreq should be optional and
selectable in Kconfig so that systems which don't need that, don't
have to see or use it. It is yet another feature which doesn't apply
universally so we make such features optional. Like the rest of the
gazillion things in the kernel already.
The existing sysfs layout cannot be changed because you're breaking
userspace and we don't do that. It is that simple.
Concerning adding new sysfs entries, I told you to make it as easy as
possible and as sensible as possible, dictated by the use cases. If you
can't come up with some, then talk to the people who are going to use
your design and ask them what makes sense the most.
*Then* write the code.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2013-02-05 9:15 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 11:38 [PATCH 0/4] CPUFreq: Implement per policy instances of governors Viresh Kumar
2013-02-04 11:38 ` [PATCH 1/4] cpufreq: Don't check cpu_online(policy->cpu) Viresh Kumar
2013-02-04 11:38 ` [PATCH 2/4] cpufreq: stats: Get rid of CPUFREQ_STATDEVICE_ATTR Viresh Kumar
2013-02-04 11:38 ` [PATCH 3/4] cpufreq: Add per policy governor-init/exit infrastructure Viresh Kumar
2013-02-04 11:38 ` [PATCH 4/4] cpufreq: governor: Implement per policy instances of governors Viresh Kumar
2013-02-10 21:14 ` Francesco Lavra
2013-02-11 4:16 ` Viresh Kumar
2013-02-11 4:39 ` Viresh Kumar
2013-02-04 12:17 ` [PATCH 0/4] CPUFreq: " Rafael J. Wysocki
2013-02-04 12:24 ` Viresh Kumar
2013-02-04 12:32 ` Borislav Petkov
2013-02-04 12:54 ` Viresh Kumar
2013-02-04 13:04 ` Borislav Petkov
2013-02-04 13:25 ` Viresh Kumar
2013-02-04 13:36 ` Borislav Petkov
2013-02-04 13:58 ` Viresh Kumar
2013-02-04 14:09 ` Borislav Petkov
2013-02-04 14:21 ` Viresh Kumar
2013-02-04 15:05 ` Borislav Petkov
2013-02-04 15:37 ` Viresh Kumar
2013-02-04 16:50 ` Borislav Petkov
2013-02-05 7:20 ` Viresh Kumar
2013-02-05 9:15 ` Borislav Petkov [this message]
2013-02-05 9:47 ` Viresh Kumar
2013-02-05 10:27 ` Borislav Petkov
2013-02-05 10:43 ` Viresh Kumar
2013-02-05 11:04 ` Borislav Petkov
2013-02-05 11:12 ` Viresh Kumar
2013-02-05 11:19 ` Borislav Petkov
2013-02-05 11:26 ` Viresh Kumar
2013-02-05 11:32 ` Borislav Petkov
2013-02-05 12:24 ` Viresh Kumar
2013-02-05 13:22 ` Borislav Petkov
2013-02-05 13:55 ` Viresh Kumar
2013-02-05 9:36 ` Viresh Kumar
2013-02-05 11:29 ` Charles Garcia-Tobin
2013-02-05 11:39 ` Borislav Petkov
2013-02-05 18:38 ` Charles Garcia-Tobin
2013-02-05 18:44 ` Borislav Petkov
2013-02-05 16:21 ` Viresh Kumar
2013-02-06 9:58 ` Viresh Kumar
2013-02-06 10:08 ` Amit Kucheria
2013-02-06 10:15 ` Viresh Kumar
2013-02-06 10:38 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130205091532.GA4827@pd.tnic \
--to=bp@alien8.de \
--cc=Liviu.Dudau@arm.com \
--cc=Steve.Bannister@arm.com \
--cc=cpufreq@vger.kernel.org \
--cc=linaro-dev@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=robin.randhawa@arm.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox