From: Quentin Perret <qperret@google.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Arnd Bergmann <arnd@arndb.de>,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
"Cc: Android Kernel" <kernel-team@android.com>,
Todd Kjos <tkjos@google.com>,
adharmap@codeaurora.org
Subject: Re: [PATCH v2 2/2] cpufreq: Specify default governor on command line
Date: Thu, 25 Jun 2020 12:53:18 +0100 [thread overview]
Message-ID: <20200625115318.GA219598@google.com> (raw)
In-Reply-To: <CAJZ5v0g=+2OFKVk2ZnmK-33knUwqcaOOQ+q9ZWnmeoBD9KOX9g@mail.gmail.com>
On Thursday 25 Jun 2020 at 13:44:34 (+0200), Rafael J. Wysocki wrote:
> On Thu, Jun 25, 2020 at 1:36 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > This change is not right IMO. This part handles the set-policy case,
> > where there are no governors. Right now this code, for some reasons
> > unknown to me, forcefully uses the default governor set to indicate
> > the policy, which is not a great idea in my opinion TBH. This doesn't
> > and shouldn't care about governor modules and should only be looking
> > at strings instead of governor pointer.
>
> Sounds right.
>
> > Rafael, I even think we should remove this code completely and just
> > rely on what the driver has sent to us. Using the selected governor
> > for set policy drivers is very confusing and also we shouldn't be
> > forced to compiling any governor for the set-policy case.
>
> Well, AFAICS the idea was to use the default governor as a kind of
> default policy proxy, but I agree that strings should be sufficient
> for that.
I agree with all the above. I'd much rather not rely on the default
governor name to populate the default policy, too, so +1 from me.
Thanks,
Quentin
WARNING: multiple messages have this Message-ID (diff)
From: Quentin Perret <qperret@google.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Juri Lelli <juri.lelli@redhat.com>,
"Cc: Android Kernel" <kernel-team@android.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
Linux PM <linux-pm@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
adharmap@codeaurora.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Todd Kjos <tkjos@google.com>
Subject: Re: [PATCH v2 2/2] cpufreq: Specify default governor on command line
Date: Thu, 25 Jun 2020 12:53:18 +0100 [thread overview]
Message-ID: <20200625115318.GA219598@google.com> (raw)
In-Reply-To: <CAJZ5v0g=+2OFKVk2ZnmK-33knUwqcaOOQ+q9ZWnmeoBD9KOX9g@mail.gmail.com>
On Thursday 25 Jun 2020 at 13:44:34 (+0200), Rafael J. Wysocki wrote:
> On Thu, Jun 25, 2020 at 1:36 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > This change is not right IMO. This part handles the set-policy case,
> > where there are no governors. Right now this code, for some reasons
> > unknown to me, forcefully uses the default governor set to indicate
> > the policy, which is not a great idea in my opinion TBH. This doesn't
> > and shouldn't care about governor modules and should only be looking
> > at strings instead of governor pointer.
>
> Sounds right.
>
> > Rafael, I even think we should remove this code completely and just
> > rely on what the driver has sent to us. Using the selected governor
> > for set policy drivers is very confusing and also we shouldn't be
> > forced to compiling any governor for the set-policy case.
>
> Well, AFAICS the idea was to use the default governor as a kind of
> default policy proxy, but I agree that strings should be sufficient
> for that.
I agree with all the above. I'd much rather not rely on the default
governor name to populate the default policy, too, so +1 from me.
Thanks,
Quentin
next prev parent reply other threads:[~2020-06-25 11:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 14:21 [PATCH v2 0/2] cpufreq: Specify the default governor on command line Quentin Perret
2020-06-23 14:21 ` Quentin Perret
2020-06-23 14:21 ` [PATCH v2 1/2] cpufreq: Register governors at core_initcall Quentin Perret
2020-06-23 14:21 ` Quentin Perret
2020-06-23 14:21 ` [PATCH v2 2/2] cpufreq: Specify default governor on command line Quentin Perret
2020-06-23 14:21 ` Quentin Perret
2020-06-24 5:50 ` Viresh Kumar
2020-06-24 5:50 ` Viresh Kumar
2020-06-24 12:51 ` Rafael J. Wysocki
2020-06-24 12:51 ` Rafael J. Wysocki
2020-06-24 15:32 ` Quentin Perret
2020-06-24 15:32 ` Quentin Perret
2020-06-25 8:50 ` Viresh Kumar
2020-06-25 8:50 ` Viresh Kumar
2020-06-25 10:52 ` Rafael J. Wysocki
2020-06-25 10:52 ` Rafael J. Wysocki
2020-06-25 11:36 ` Viresh Kumar
2020-06-25 11:36 ` Viresh Kumar
2020-06-25 11:44 ` Rafael J. Wysocki
2020-06-25 11:44 ` Rafael J. Wysocki
2020-06-25 11:53 ` Quentin Perret [this message]
2020-06-25 11:53 ` Quentin Perret
2020-06-25 13:28 ` Rafael J. Wysocki
2020-06-25 13:28 ` Rafael J. Wysocki
2020-06-25 13:49 ` Quentin Perret
2020-06-25 13:49 ` Quentin Perret
2020-06-25 14:08 ` Rafael J. Wysocki
2020-06-25 14:08 ` Rafael J. Wysocki
2020-06-26 2:53 ` Viresh Kumar
2020-06-26 2:53 ` Viresh Kumar
2020-06-26 8:09 ` Quentin Perret
2020-06-26 8:09 ` Quentin Perret
2020-06-23 17:54 ` [PATCH v2 0/2] cpufreq: Specify the " Doug Smythies
2020-06-23 17:54 ` Doug Smythies
2020-06-23 18:04 ` Quentin Perret
2020-06-23 18:04 ` Quentin Perret
2020-06-24 0:07 ` Doug Smythies
2020-06-24 0:07 ` Doug Smythies
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=20200625115318.GA219598@google.com \
--to=qperret@google.com \
--cc=adharmap@codeaurora.org \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tkjos@google.com \
--cc=vincent.guittot@linaro.org \
--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 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.