On Fri, Jun 23, 2017 at 04:15:07PM +0100, James Hogan wrote: > On Thu, Jun 22, 2017 at 11:06:55PM +0800, Huacai Chen wrote: > > diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c > > index 4eff2ae..78db63a 100644 > > --- a/arch/mips/kernel/proc.c > > +++ b/arch/mips/kernel/proc.c > > > @@ -62,6 +63,9 @@ static int show_cpuinfo(struct seq_file *m, void *v) > > seq_printf(m, fmt, __cpu_name[n], > > (version >> 4) & 0x0f, version & 0x0f, > > (fp_vers >> 4) & 0x0f, fp_vers & 0x0f); > > + if (__cpu_full_name[n]) > > + seq_printf(m, "model name\t\t: %s @ %uMHz\n", > > + __cpu_full_name[n], mips_hpt_frequency / 500000); > > If the core frequency is useful (I can imagine it being useful for > humans), maybe it should be on a separate line. > > This also assumes that the mips_hpt_frequency is half the core > frequency, which may not universally be the case. Perhaps that should be > abstracted too (at some point, I suppose it doesn't matter right away). Indeed, there is a number of cores where the counter is incrementing at the full clock rate and some - I think this was the IDT 5230/5260 class of devices where the clock rate can be configured through a cold reset time bitstream but the rate in use can not be detected by software in a configuration register, so it has to be meassured by comparing to another known clock. Whops.. Making the clock part of the name is probably sensible on x86 where there seem to be different CPU packages being marketed for different clock rates, so this is more of a marketing name in contrast to an actual core type. It's not like on MIPS we're not suffering from creative CPU naming as well. It all started in '91 with when the R4000 with its 8k primary caches was upgraded and then primarily due to its 16k caches sold as the R4400. From a software perspective there isn't much of a difference so calling the R4400 an R4000 is sensible but users might miss an inch or two if their R4400 is called a lowly R4000 ;-) Ralf
