[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKohpomZeD-1gsh-u_wyabaYLoqm3A=cyUNyZDMmzE3_fKA8-g@mail.gmail.com>
Date: Tue, 19 Nov 2013 19:52:14 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: "Jon Medhurst (Tixy)" <tixy@...aro.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Nishanth Menon <nm@...com>,
Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Patch Tracking <patches@...aro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
Carlos Hernandez <ceh@...com>
Subject: Re: [PATCH] cpufreq/stats: Add "unknown" frequency field in stats tables
On 19 November 2013 14:12, Jon Medhurst (Tixy) <tixy@...aro.org> wrote:
> I'm wondering if this would break any user-side code parsing this output
> and does that matter? (E.g. powertop will end up doing strtoull on
> "unknown" and get zero as the frequency.) Would omitting 'unknown' if
> the time is zero be safer in this repect? Possibly not, inconsistency is
> probably worse than change.
We wouldn't know about this on bootup all the time. I thought of doing
this only when an invalid frequency is configured at boot. Because after
that cpufreq will never configure any freq out of freq-table.
But in case of suspend/resume control again goes to bootloaders and
they might end up configuring unknown freq again. And we aren't
allocating these data structures on suspend resume but only during
system boot.
Even if powertop reads it zero then also it isn't that bad.. because the
other option we had was to mark it zero or -1 (uint max).. But unknown
looks better for readability..
--
viresh
--
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/
Powered by blists - more mailing lists