On 24 March 2013 21:16, Arnd Bergmann <a...@arndb.de> wrote: > On Sunday 24 March 2013, Peter Maydell wrote: >> Yeah, ideally being able to detect the buggy kernel would be good; >> I can't see anything at the controller level that would do though, >> and I don't really know enough about PCI to know about generic >> PCI stuff that would work. (Why would the OS need to tell the >> device anything about its IRQ if it's hardwired?) > > I think it actually does on versatile and other platforms on which > the kernel probes the PCI bus itself, rather than relying on firmware > to have resources assigned in advance. > > IIRC, the PCI_INTERRUPT_LINE pci config space byte (0x3c) is purely > informational and used as a way to communicate the interrupt number > from the bus scan code (assumed to be a PC BIOS in the PCI spec, > but drivers/pci/setup-irq.c in case of versatile+linux) to a device > driver. > > So the kernel should actually write the proper interrupt number in > there. In future kernels, this may not necessarily be the hardware > number, but today it is. Can you try out what the kernel writes into > that register in qemu, with and without my patches?
OK, I'll give that a go tomorrow. While you're here, do you know what the point of the PCI_SELFID register is? The h/w docs are clear that the OS has to write the slot number of the board itself in to this register, but again I don't see why the OS has to tell the hardware something it already knows. On QEMU I just implemented this register as a no-op and everything seems to still function... thanks -- PMM
