Re: [PATCH] MIPS: Fix CP0 counter erratum detection for R4k CPUs

From: Thomas Bogendoerfer
Date: Fri Apr 29 2022 - 06:01:51 EST

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

interesting, where is this documented ? And it's quite funny that so far
everybody messed up revision printing for R4400 CPUs.

> 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?

all SNI systems have a i8254 in their EISA/PCI chipsets. But they aren't
that nice for clock events as their interupts are connected via an i8259
addresses via ISA PIO.

> With the considerations above in mind, please apply.

will do later.


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