On Fri, Jan 18, 2013 at 03:32:45PM +0000, Matthew Garrett wrote:
> On Fri, 2013-01-18 at 16:26 +0100, Borislav Petkov wrote:
> > Yep, that should be one way to fix it.
> >
> > One other fix IMHO would be if udev is looking at CPUID bits, to teach
> > it to check the proper P-States feature bits on Intel and AMD:
>
> I think it makes more sense to use the existing CPU modaliases than to
> special-case it in udev.
Well, actually, those CPUID bits are there for exactly that reason: to
query them and enable software features. And this is one of the reasons
CPUID is a ring 3 instruction: so that even userspace can use it.
So, in a perfect world, udev should simply run CPUID, check the
respective bits, and, if they're set, load the respective driver. That
is, if it doesn't do it already.
No need for additional code glue in the kernel or anywhere else.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
