linux-kernel - Re: [PATCH V4 1/2] cpufreq: Mark x86 drivers with CPUFREQ_SKIP_INITIAL_FREQ

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: <CAKohpo=mqqCjjOpEAMHo385h=DVcw3Hn9GX9yGXFP_YHcyNBtw@mail.gmail.com>
Date:	Tue, 3 Dec 2013 11:18:01 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Dirk Brandewie <dirk.brandewie@...il.com>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Patch Tracking <patches@...aro.org>,
	"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>,
	Nishanth Menon <nm@...com>, Carlos Hernandez <ceh@...com>
Subject: Re: [PATCH V4 1/2] cpufreq: Mark x86 drivers with CPUFREQ_SKIP_INITIAL_FREQ_CHECK
 flag

On 3 December 2013 04:03, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> On Monday, December 02, 2013 07:23:01 AM Dirk Brandewie wrote:
>> Sorry for late response to these threads.  Holiday weekend in the US.

No issues.

>> NAK for intel_pstate.  The code that will use this flag also uses has_target()
>> which is false for intel_pstate.
>
> Is your point that intel_pstate doesn't need to have this flag set?

Probably yes as intel_pstate would never share freq-table. Will fix this.

>> I still believe that this bug should be dealt with in platform specific code
>> since this is working around a bootloader bug.  Are there platforms in the wild
>> that even need this code or is this to support early platform bringup?
>
> All it takes to introduce it is to use a buggy bootloader, so I guess
> there's a number of potentially affected platforms out there.

Yeah. This was first reported for OMAP SoC's though.

> This really isn't about which individual platforms have the problem, but about
> which platforms have the property that the clock *can* be set to a wrong
> frequency initially.  These are the ones we need to worry about regardless,
> because we can't control boot loaders and duplicating the same code in
> a number of drivers doesn't sound like a good approach.
>
> So the only reasonable way forward I can see is to flag either the platforms
> that we need to worry about, or the platforms that we don't need to worry
> about and use that to decide whether or not to do the check.

To be honest Rafael suggested exactly this initially, i.e. set flag for all the
drivers which want this to be done and I thought the number of drivers that
don't want it would be lesser and so it would be easier to set this flag there.

But looking at the logic Dirk gave, it makes sense to do this for drivers which
want this feature to be enabled. Moreover we really can't say for how long
these drivers will continue keeping this flag as I don't really think its a bug.
Kernel can't expect bootloaders to set core to a frequency which should be
exactly same as what cpufreq table has. And so this flag may stay until
cpufreq is around :)

I will send updated patches soon..

--
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/