On Mon, May 25, 2015 at 12:15:21AM -0400, Joshua Kinard wrote: > From: Joshua Kinard <kumba@xxxxxxxxxx> > > Currently, arch/mips/oprofile/op_model_mipsxx.c treats an R14000 as an > R12000. This patch distinguishes one from the other. > > Signed-off-by: Joshua Kinard <kumba@xxxxxxxxxx> > --- > op_model_mipsxx.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > linux-mips-oprofile-fix-r14k.patch > diff --git a/arch/mips/oprofile/op_model_mipsxx.c b/arch/mips/oprofile/op_model_mipsxx.c > index 6a6e2cc..75f1967 100644 > --- a/arch/mips/oprofile/op_model_mipsxx.c > +++ b/arch/mips/oprofile/op_model_mipsxx.c > @@ -408,10 +408,13 @@ static int __init mipsxx_init(void) > break; > > case CPU_R12000: > - case CPU_R14000: > op_model_mipsxx_ops.cpu_type = "mips/r12000"; > break; > > + case CPU_R14000: > + op_model_mipsxx_ops.cpu_type = "mips/r14000"; > + break; > + Note the string returned here is exported to userland which uses it to lookup event and unit_mask definitions in /usr/share/oprofile. In other words without changes to userland oprofile you've just broken R14000 oprofile support. Due to the large number of such files it is only acceptable to add new such files for CPUs that differ significantly from other CPUs. This is not the case for the R14000 which supports the same events as the R12000, so this patch is wrong, sorry. I don't want to think about what the mixing R10000 and R12000/R14000 in a single system means for using oprofile ... Ralf
