On Sun, Oct 03, 2010 at 10:58:30PM -0700, Warren Turkal wrote: > Are there processors where that CPU_ADDR_BITS_MASK cannot be reliably > retrieved from CPUID? What is the harm in using a value that is too
Looks like there are, at least a code comment which was in there suggests that: /* * This routine needs to know how many address bits a given processor supports * (CONFIG_CPU_ADDR_BITS). CPUs get grumpy when you set too many bits in * their MTRR registers. We could generically use CPUID here and find out how * many are physically supported, but some CPUs are buggy, and report more * bits than they actually support. */ But I agree with you, I'd personally have no objections to using CPUID per default, and allowing a "black-list" via kconfig variables which use a value from the CPU's Kconfig if this CPU is known-bad (i.e. reports an incorrect bit number). Something like select CPU_REPORTS_INVALID_ADDR_BITS_NUMBER > small for the CAR setup? In other words could we use the least common > value for any CPU instead of having a different setting on each > different chip? What do you mean with "chip" here? The value is CPU-specific (not socket-specific or board-specific). It's also implemented using a per-CPU mechanism via kconfig in my patch. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
