summaryrefslogtreecommitdiffstats
path: root/arch/mips/include/asm/timex.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* MIPS: Fix typosBjorn Helgaas2024-01-081-1/+1
| | | | | | | | | | Fix typos, most reported by "codespell arch/mips". Only touches comments, no code changes. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: linux-mips@vger.kernel.org Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
* mips: use fallback for random_get_entropy() instead of just c0 randomJason A. Donenfeld2022-05-131-9/+8
| | | | | | | | | | | | | | | | | | | For situations in which we don't have a c0 counter register available, we've been falling back to reading the c0 "random" register, which is usually bounded by the amount of TLB entries and changes every other cycle or so. This means it wraps extremely often. We can do better by combining this fast-changing counter with a potentially slower-changing counter from random_get_entropy_fallback() in the more significant bits. This commit combines the two, taking into account that the changing bits are in a different bit position depending on the CPU model. In addition, we previously were falling back to 0 for ancient CPUs that Linux does not support anyway; remove that dead path entirely. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Arnd Bergmann <arnd@arndb.de> Tested-by: Maciej W. Rozycki <macro@orcam.me.uk> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* MIPS: Fix CP0 counter erratum detection for R4k CPUsMaciej W. Rozycki2022-04-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 RandomMaciej W. Rozycki2014-05-301-18/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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().Ralf Baechle2013-09-181-1/+32
| | | | | | | | | | | | | 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/includeRalf Baechle2008-10-111-0/+43
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>