linux-toradex.git/arch/mips/include/asm/timex.h, branch v5.18 Linux kernel for Apalis and Colibri modules MIPS: Fix CP0 counter erratum detection for R4k CPUs 2022-04-29T13:52:00+00:00 Maciej W. Rozycki macro@orcam.me.uk 2022-04-24T11:46:23+00:00 f0a6c68f69981214cb7858738dd2bc81475111f7 Fix the discrepancy between the two places we check for the CP0 counter erratum in along with the incorrect comparison of the R4400 revision number against 0x30 which matches none and consistently consider all R4000 and R4400 processors affected, as documented in processor errata publications[1][2][3], following the mapping between CP0 PRId register values and processor models: PRId | Processor Model ---------+-------------------- 00000422 | R4000 Revision 2.2 00000430 | R4000 Revision 3.0 00000440 | R4400 Revision 1.0 00000450 | R4400 Revision 2.0 00000460 | R4400 Revision 3.0 No other revision of either processor has ever been spotted. Contrary to what has been stated in commit ce202cbb9e0b ("[MIPS] Assume R4000/R4400 newer than 3.0 don't have the mfc0 count bug") marking the CP0 counter as buggy does not preclude it from being used as either a clock event or a clock source device. It just cannot be used as both at a time, because in that case clock event interrupts will be occasionally lost, and the use as a clock event device takes precedence. Compare against 0x4ff in `can_use_mips_counter' so that a single machine instruction is produced. References: [1] "MIPS R4000PC/SC Errata, Processor Revision 2.2 and 3.0", MIPS Technologies Inc., May 10, 1994, Erratum 53, p.13 [2] "MIPS R4400PC/SC Errata, Processor Revision 1.0", MIPS Technologies Inc., February 9, 1994, Erratum 21, p.4 [3] "MIPS R4400PC/SC Errata, Processor Revision 2.0 & 3.0", MIPS Technologies Inc., January 24, 1995, Erratum 14, p.3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: ce202cbb9e0b ("[MIPS] Assume R4000/R4400 newer than 3.0 don't have the mfc0 count bug") Cc: stable@vger.kernel.org # v2.6.24+ Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> 
Fix the discrepancy between the two places we check for the CP0 counter
erratum in along with the incorrect comparison of the R4400 revision
number against 0x30 which matches none and consistently consider all
R4000 and R4400 processors affected, as documented in processor errata
publications[1][2][3], following the mapping between CP0 PRId register
values and processor models:

  PRId   |  Processor Model
---------+--------------------
00000422 | R4000 Revision 2.2
00000430 | R4000 Revision 3.0
00000440 | R4400 Revision 1.0
00000450 | R4400 Revision 2.0
00000460 | R4400 Revision 3.0

No other revision of either processor has ever been spotted.

Contrary to what has been stated in commit ce202cbb9e0b ("[MIPS] Assume
R4000/R4400 newer than 3.0 don't have the mfc0 count bug") marking the
CP0 counter as buggy does not preclude it from being used as either a
clock event or a clock source device.  It just cannot be used as both at
a time, because in that case clock event interrupts will be occasionally
lost, and the use as a clock event device takes precedence.

Compare against 0x4ff in `can_use_mips_counter' so that a single machine
instruction is produced.

References:

[1] "MIPS R4000PC/SC Errata, Processor Revision 2.2 and 3.0", MIPS
    Technologies Inc., May 10, 1994, Erratum 53, p.13

[2] "MIPS R4400PC/SC Errata, Processor Revision 1.0", MIPS Technologies
    Inc., February 9, 1994, Erratum 21, p.4

[3] "MIPS R4400PC/SC Errata, Processor Revision 2.0 & 3.0", MIPS
    Technologies Inc., January 24, 1995, Erratum 14, p.3

Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Fixes: ce202cbb9e0b ("[MIPS] Assume R4000/R4400 newer than 3.0 don't have the mfc0 count bug")
Cc: stable@vger.kernel.org # v2.6.24+
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
MIPS: Implement random_get_entropy with CP0 Random 2014-05-30T16:21:30+00:00 Maciej W. Rozycki macro@linux-mips.org 2014-04-06T20:31:29+00:00 06947aaaf9bf7da0b29e211ee1a44f3ca91c08fa Update to commit 9c9b415c50bc298ac61412dff856eae2f54889ee [MIPS: Reimplement get_cycles().] On systems were for whatever reasons we can't use the cycle counter, fall back to the c0_random register as an entropy source. It has however a very small range that makes it suitable for random_get_entropy only and not get_cycles. This optimised version compiles to 8 instructions in the fast path even in the worst case of all the conditions to check being variable (including a MFC0 move delay slot that is only required for very old processors): 828: 8cf90000 lw t9,0(a3) 828: R_MIPS_LO16 jiffies 82c: 40057800 mfc0 a1,c0_prid 830: 3c0200ff lui v0,0xff 834: 00a21024 and v0,a1,v0 838: 1040007d beqz v0,a30 <add_interrupt_randomness+0x22c> 83c: 3c030000 lui v1,0x0 83c: R_MIPS_HI16 cpu_data 840: 40024800 mfc0 v0,c0_count 844: 00000000 nop 848: 00409021 move s2,v0 84c: 8ce20000 lw v0,0(a3) 84c: R_MIPS_LO16 jiffies On most targets the sequence will be shorter and on some it will reduce to a single `MFC0 <reg>,c0_count', as all MIPS architecture (i.e. non-legacy MIPS) processors require the CP0 Count register to be present. The only known exception that reports MIPS architecture compliance, but contrary to that lacks CP0 Count is the Ingenic JZ4740 thingy. For broken platforms like that this code requires cpu_has_counter to be hardcoded to 0 (i.e. no variable setting is permitted) so as not to penalise all the other good platforms out there. The asm barrier is required so that the compiler does not pull any potentially costly (cold cache!) `cpu_data' variable access into the fast path. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: Theodore Ts'o <tytso@mit.edu> Cc: John Crispin <blogic@openwrt.org> Cc: Andrew McGregor <andrewmcgr@gmail.com> Cc: Dave Taht <dave.taht@bufferbloat.net> Cc: Felix Fietkau <nbd@nbd.name> Cc: Simon Kelley <simon@thekelleys.org.uk> Cc: Jim Gettys <jg@freedesktop.org> Cc: David Daney <ddaney@caviumnetworks.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6702/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
Update to commit 9c9b415c50bc298ac61412dff856eae2f54889ee [MIPS:
Reimplement get_cycles().]

On systems were for whatever reasons we can't use the cycle counter, fall
back to the c0_random register as an entropy source.  It has however a
very small range that makes it suitable for random_get_entropy only and
not get_cycles.

This optimised version compiles to 8 instructions in the fast path even in
the worst case of all the conditions to check being variable (including a
MFC0 move delay slot that is only required for very old processors):

     828:	8cf90000 	lw	t9,0(a3)
			828: R_MIPS_LO16	jiffies
     82c:	40057800 	mfc0	a1,c0_prid
     830:	3c0200ff 	lui	v0,0xff
     834:	00a21024 	and	v0,a1,v0
     838:	1040007d 	beqz	v0,a30 <add_interrupt_randomness+0x22c>
     83c:	3c030000 	lui	v1,0x0
			83c: R_MIPS_HI16	cpu_data
     840:	40024800 	mfc0	v0,c0_count
     844:	00000000 	nop
     848:	00409021 	move	s2,v0
     84c:	8ce20000 	lw	v0,0(a3)
			84c: R_MIPS_LO16	jiffies

On most targets the sequence will be shorter and on some it will reduce to
a single `MFC0 <reg>,c0_count', as all MIPS architecture (i.e. non-legacy
MIPS) processors require the CP0 Count register to be present.

The only known exception that reports MIPS architecture compliance, but
contrary to that lacks CP0 Count is the Ingenic JZ4740 thingy.  For broken
platforms like that this code requires cpu_has_counter to be hardcoded to
0 (i.e. no variable setting is permitted) so as not to penalise all the
other good platforms out there.

The asm barrier is required so that the compiler does not pull any
potentially costly (cold cache!) `cpu_data' variable access into the fast
path.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: John Crispin <blogic@openwrt.org>
Cc: Andrew McGregor <andrewmcgr@gmail.com>
Cc: Dave Taht <dave.taht@bufferbloat.net>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Simon Kelley <simon@thekelleys.org.uk>
Cc: Jim Gettys <jg@freedesktop.org>
Cc: David Daney <ddaney@caviumnetworks.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6702/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Reimplement get_cycles(). 2013-09-18T14:31:49+00:00 Ralf Baechle ralf@linux-mips.org 2013-09-12T11:47:32+00:00 9c9b415c50bc298ac61412dff856eae2f54889ee This essentially reverts commit efb9ca08b5a2374b29938cdcab417ce4feb14b54 (kernel.org) / 58020a106879a8b372068741c81f0015c9b0b96dbv [[MIPS] Change get_cycles to always return 0.] Most users of get_cycles() invoke it as a timing interface. That's why in modern kernels it was never very much missed for. /dev/random however uses get_cycles() in the how the jitter in the interrupt timing contains some useful entropy. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
This essentially reverts commit efb9ca08b5a2374b29938cdcab417ce4feb14b54
(kernel.org) / 58020a106879a8b372068741c81f0015c9b0b96dbv [[MIPS] Change
get_cycles to always return 0.]

Most users of get_cycles() invoke it as a timing interface.  That's why
in modern kernels it was never very much missed for.  /dev/random however
uses get_cycles() in the how the jitter in the interrupt timing contains
some useful entropy.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Move headfiles to new location below arch/mips/include 2008-10-11T15:18:52+00:00 Ralf Baechle ralf@linux-mips.org 2008-09-16T17:48:51+00:00 384740dc49ea651ba350704d13ff6be9976e37fe Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>