linux-kernel - Re: [PATCH 07/10] cpufreq: Add support for x86 cpuinfo auto loading

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 7 Dec 2011 20:24:29 -0500
From:	Dave Jones <davej@...hat.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, kay.sievers@...y.org, trenn@...e.de,
	Andi Kleen <ak@...ux.intel.com>, hpa@...or.com
Subject: Re: [PATCH 07/10] cpufreq: Add support for x86 cpuinfo auto loading

On Thu, Dec 08, 2011 at 02:13:56AM +0100, Andi Kleen wrote:

 > > This makes e_powersaver bind to every family 6 VIA cpu.
 > > But the old logic only bound to certain models.
 > > Won't this will clash with this other driver if both are built ?
 > 
 > The code does
 > 
 > static int __init eps_init(void)
 > {
 >         if (!x86_match_cpu(eps_cpu_id) || boot_cpu_data.x86_model < 10)
 >                 return -ENODEV;
 > 
 > So modprobe will load it, but if the CPU is too old it will just error out
 > again. I think that's reasonable.  There's no direct way current
 > to express a >= in the matches because modprobe uses fnmatch()
 > 
 > Also most likely the old CPUs won't have the EST bit anyways, then
 > it won't even be loaded.

I don't have any VIA CPUs to check any more, and my memory is a little vague,
but I think you're right on this assumption.

 > > iirc, the intention here was longhaul on cpus that don't have EST,
 > > and e_powersaver on those that do. Maybe an additional check for the
 > > absense of EST in longhaul's init code would do the trick.
 > > (sidenote: I don't recall why we even have e-powersaver, instead of them
 > >  just using acpi-cpufreq).
 > 
 > It's not done today, but I could add it. 
 > 
 > But I tried to keep the existing behaviour. 
 > This matches this. I have no way to test these CPUs so I would 
 > prefer to be as compatible as possible.

That's fine. Don't sweat it for this, it's something that could be done later
if someone cares enough. We might have a hard time finding someone even
still using this driver.

 > AFAIK distros just load them all right?

In Fedora, we used to. In F16, we changed things so instead of a monstrous
init script with nested if's and a whole bunch of hairy logic, we changed
all the modules to be built-in's, and relied on the link-order in the cpufreq Makefile
to satisfy the 'first to bind wins'.

Yes, ugly, but we didn't have this patchset ;-) 

	Dave

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