[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bbf5d417ee0d4edbbed31f19ef40fad0@AcuMS.aculab.com>
Date: Fri, 14 May 2021 13:13:19 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Thomas Gleixner' <tglx@...utronix.de>,
'Maximilian Luz' <luzmaximilian@...il.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>
CC: "H. Peter Anvin" <hpa@...or.com>, Sachi King <nakato@...ato.io>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH] x86/i8259: Work around buggy legacy PIC
From: Thomas Gleixner
> Sent: 14 May 2021 14:02
>
> David,
>
> On Thu, May 13 2021 at 10:36, David Laight wrote:
>
> >> -----Original Message-----
> >> From: Maximilian Luz <luzmaximilian@...il.com>
>
> can you please fix your mail client and spare us the useless header
> duplication in the reply?
I have to delete them by hand - must have forgotten, I can't fix outlook :-)
> > It is also worth noting that the probe code is spectacularly crap.
> > It writes 0xff and then checks that 0xff is read back.
> > Almost anything (including a failed PCIe read to the ISA bridge)
> > will return 0xff and make the test pass.
>
> unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
>
> outb(probe_val, PIC_MASTER_IMR);
> new_val = inb(PIC_MASTER_IMR);
>
> How is that writing 0xFF?
Sorry I misread the code and diagnostic output.
In any case writing a value and expecting the same value back
isn't exactly a high-quality probe.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists