From: Viresh Kumar <viresh.kumar@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org, Mason <slash.tmp@free.fr>,
linux-pm <linux-pm@vger.kernel.org>
Subject: Re: [PATCH RFC] Add cpufreq support
Date: Mon, 8 Feb 2016 18:11:27 +0530 [thread overview]
Message-ID: <20160208124127.GF8294@vireshk> (raw)
In-Reply-To: <45004963.Im3DmqJ5ez@wuerfel>
On 08-02-16, 13:34, Arnd Bergmann wrote:
> Maybe add a opp-v3 compatible string?
How will that help?
The problem was that the compatibility string of "opp-v2" specifies
the way we need to parse the bindings and shouldn't be (ab)used to
probe a driver like cpufreq-dt. And so we got stuck.
> I really don't care what you
> match on, as long we don't need any code in arch/arm/ to create a
> device we don't need.
Sure.
> Don't add the device to DT, we really don't want that.
I agree.
> If there
> is too much opposition to looking at the cpus nodes in the initcall,
I didn't get this one, what can we do by looking at CPUs nodes ?
> start with a whitelist for known machines, that at least keeps the
> existing behavior.
That can be a valid solution I would say, but that separate driver
(cpufreq-dt-device.c) needs to be changed for every new platform.
--
viresh
WARNING: multiple messages have this Message-ID (diff)
From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC] Add cpufreq support
Date: Mon, 8 Feb 2016 18:11:27 +0530 [thread overview]
Message-ID: <20160208124127.GF8294@vireshk> (raw)
In-Reply-To: <45004963.Im3DmqJ5ez@wuerfel>
On 08-02-16, 13:34, Arnd Bergmann wrote:
> Maybe add a opp-v3 compatible string?
How will that help?
The problem was that the compatibility string of "opp-v2" specifies
the way we need to parse the bindings and shouldn't be (ab)used to
probe a driver like cpufreq-dt. And so we got stuck.
> I really don't care what you
> match on, as long we don't need any code in arch/arm/ to create a
> device we don't need.
Sure.
> Don't add the device to DT, we really don't want that.
I agree.
> If there
> is too much opposition to looking at the cpus nodes in the initcall,
I didn't get this one, what can we do by looking at CPUs nodes ?
> start with a whitelist for known machines, that at least keeps the
> existing behavior.
That can be a valid solution I would say, but that separate driver
(cpufreq-dt-device.c) needs to be changed for every new platform.
--
viresh
next prev parent reply other threads:[~2016-02-08 12:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 16:58 [PATCH RFC] Add cpufreq support Mason
2016-02-05 16:58 ` Mason
2016-02-05 22:24 ` Arnd Bergmann
2016-02-05 22:24 ` Arnd Bergmann
2016-02-07 12:22 ` Viresh Kumar
2016-02-07 12:22 ` Viresh Kumar
2016-02-08 12:24 ` Arnd Bergmann
2016-02-08 12:24 ` Arnd Bergmann
2016-02-08 12:31 ` Viresh Kumar
2016-02-08 12:31 ` Viresh Kumar
2016-02-08 12:34 ` Arnd Bergmann
2016-02-08 12:34 ` Arnd Bergmann
2016-02-08 12:41 ` Viresh Kumar [this message]
2016-02-08 12:41 ` Viresh Kumar
2016-02-08 13:10 ` Arnd Bergmann
2016-02-08 13:10 ` Arnd Bergmann
2016-02-08 13:16 ` Viresh Kumar
2016-02-08 13:16 ` Viresh Kumar
2016-02-08 13:45 ` Arnd Bergmann
2016-02-08 13:45 ` Arnd Bergmann
2016-02-09 10:17 ` Mason
2016-02-09 10:17 ` Mason
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=20160208124127.GF8294@vireshk \
--to=viresh.kumar@linaro.org \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=slash.tmp@free.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.