On Sun, 8 Dec 2002, Richard Henderson wrote:
>
> It just reports what's in the PCI_INTERRUPT_LINE register.
That's wrong, then.
> At least on Alpha, we wrote into this register during pci
> configuration, so the value matches what's in /proc/interrupts.
> I guess I always assumed we did the same on x86, but I've
> never checked.
It _shouldn't_ be done. The PCI_INTERRUPT_LINE register is just a byte,
which isn't even _enough_ to identify the irq "for real" on many
architectures. It's also a totally different namespace at least on x86
machines: the PCI_INTERRUPT_LINE register should contain the "legacy
interrupt", while the remapped interrupt will depend on whether the
io-apic is enabled or not.
Writing it back is actively _bad_, since it will make it very hard to
re-boot the machine without the BIOS re-enumarating the PCI bus and
filling it in again (ie it would definitely screw up using things like
kexec() on PC's, if the kernel we boot _from_ is an APIC kernel, but the
kernel we boot _into_ is not).
So the rule should be:
- the PCI config space is _not_ the same as "pci->irq"
- we should _never_ update the PCI_INTERRUPT_LINE register, because it
destroys boot loader information (the same way we need to not overwrite
BIOS extended areas and ACPI areas etc in order to be able to reboot
cleanly)
- we need _some_ way of getting the "kernel irq line" from /sys or /proc.
Sounds like /proc/pci still does something for us. Or is the info
available in /proc/bus/pci/devices?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 15 2002 - 22:00:13 EST