Message-ID: <20220429135338.GA3357@alpha.franken.de>
Date:   Fri, 29 Apr 2022 15:53:38 +0200
From:   Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH] MIPS: Fix CP0 counter erratum detection for R4k CPUs

On Sun, Apr 24, 2022 at 12:46:23PM +0100, Maciej W. Rozycki wrote:
> 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@...am.me.uk>
> Fixes: ce202cbb9e0b ("[MIPS] Assume R4000/R4400 newer than 3.0 don't have the mfc0 count bug")
> Cc: stable@...r.kernel.org # v2.6.24+
> ---
> Thomas,
> 
>  Please review the requirements for SNI platforms.  In the case of an 
> erratic CP0 timer we give precedence to the use as a clock event rather 
> than clock source device; see `time_init' in arch/mips/kernel/time.c. 
> Therefore if SNI systems have no alternative timer interrupt source, then 
> the CP0 timer is supposed to still do regardless of the erratum.
> 
>  Conversely a system can do without a high-precision clock source, in
> which case jiffies will be used.  Of course such a system will suffer if 
> used for precision timekeeping, but such is the price for broken hardware.  
> Don't SNI systems have any alternative timer available, not even the 
> venerable 8254?
> 
>  Long-term I think this code should be factored out and rewritten so that 
> it lives in one place and can take advantage of compile-time constants, 
> which will be the case for the majority of platforms.  For the time being 
> fix the immediate breakage however.
> 
>  With the considerations above in mind, please apply.
> 
>   Maciej
> ---
>  arch/mips/include/asm/timex.h |    8 ++++----
>  arch/mips/kernel/time.c       |   11 +++--------
>  2 files changed, 7 insertions(+), 12 deletions(-)

applied to mips-fixes.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Powered by blists - more mailing lists