lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKohponyFja18pqn5UL9bbtf_M4twWEyL3YqDGX5dgpdeRnJ_A@mail.gmail.com>
Date:	Mon, 18 Nov 2013 21:13:14 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Nishanth Menon <nm@...com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Carlos Hernandez <ceh@...com>,
	Tobias Diedrich <ranma+xen@...edrich.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Dave Jones <davej@...hat.com>
Subject: Re: [PATCH] cpufreq: stats: Do not populate stats when policy->cur
 has no exact match

On 18 November 2013 21:04, Nishanth Menon <nm@...com> wrote:
> depends on how we look at it.. if we consider freq_table as a list of
> valid frequencies, anything that is not in there is an invalid entry.

Partly correct. Yes freq table has a list of valid frequencies, but normally
we just build a table of definite length which will cover frequencies of
all ranges.. Our plls allow us to configure other frequencies too and
they are valid too.. So, we really can't call that invalid.. Though they
must be called out of range? or something better?

> why should stat support it when freq_table is enforced by cpufreq layer?

We are not supporting them, and so had a single entry for them. It is
just to show to user that we are actually running on some freq outside
of table. You better check if that's fine for your system or not.

> :) -> https://patchwork.kernel.org/patch/3192211/ shows how confused
> my git am  feels ;)

I am surprised to see what patchwork has done to my diff :) .. whereas
lkml shows it correctly..

https://lkml.org/lkml/2013/11/16/3

Because I haven't created a commit, it was only diff and git am couldn't
get this fixed.. So either patch -p1 < mail would have done it or maybe
its better if I paste commits..
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ