ping -----Original Message----- From: Petar Jovanovic [mailto:Petar.Jovanovic@xxxxxxxxxx] Sent: Monday, August 7, 2017 7:00 PM To: David Daney <ddaney@xxxxxxxxxxxxxxxxxx>; Maciej Rozycki <Maciej.Rozycki@xxxxxxxxxx>; Petar Jovanovic <petar.jovanovic@xxxxxxxxx>; ralf@xxxxxxxxxxxxxx Cc: linux-mips@xxxxxxxxxxxxxx; david.daney@xxxxxxxxxx Subject: RE: [PATCH] MIPS: Octeon: Expose support for mips32r1, mips32r2 and mips64r1 ________________________________________ From: David Daney [ddaney@xxxxxxxxxxxxxxxxxx] Sent: Friday, July 07, 2017 6:19 PM To: Maciej Rozycki; Petar Jovanovic; ralf@xxxxxxxxxxxxxx Cc: Petar Jovanovic; linux-mips@xxxxxxxxxxxxxx; david.daney@xxxxxxxxxx Subject: Re: [PATCH] MIPS: Octeon: Expose support for mips32r1, mips32r2 and mips64r1 On 07/07/2017 08:04 AM, Maciej W. Rozycki wrote: > On Fri, 7 Jul 2017, Petar Jovanovic wrote: > >> As I said earlier in the thread, "in the current ToT, I have not seen >> where this change would affect apart from show_cpuinfo()"[1]. So, if >> someone implements Octeon-specific controls, where this should be used? > > Right, `egrep -r 'cpu_has_(mips_r1|mips32r1|mips64r1|mips32r2)' arch/mips' > does not show anything else indeed. Please make it unambiguous in the > patch description then, i.e. that there is no functional change beyond > reporting in `show_cpuinfo'. > >> I am not aware of the places where Octeon (ab)uses it in the current >> kernel code. David says he "cannot recall exactly what the issues >> were" [2]. > > In my recent review of the code while working the the eBPF JIT, I > tried to audit the use of cpu_has_* as it relates to OCTEON. My > current thoughts are that there is no reason not to merge Petar's patch. > Ralf, please add ... > Acked-by: David Daney <david.daney@xxxxxxxxxx> > Sorry for the pain here. Ralf? Regards, Petar =
