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.