* David Laight <David.Laight@xxxxxxxxxx> wrote: > > > 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. It's not, and it's not intended to be: 0x21 is a well-known port nobody was crazy enough to override yet, so that probe basically filters out the "there is nothing at that port, at all" case, which would normally return 0xff, or in a few weird cases 0x00 perhaps. Writing something inbetween those values and getting the same value back tells us that something functional occupies that well-known IO-port, pretending to be a i8259 PIC. Which is what we wanted to know, given the context. Thanks, Ingo
