Messages in this thread | | | Date | Tue, 8 Jun 2010 20:12:58 +0100 | From | Alan Cox <> | Subject | Re: [PATCH] x86/sfi: fix ioapic gsi range |
| |
> The issue is what acpi calls bus 0 irqs, and how drivers deal with > them. We wind up having well know irqs: irqs 3 and 4 for serial > ports, irq 7 for parallel ports. irqs 14, and 15 for ide.
Only we don't.
IRQ 3/4 for serial is not true on many boxes today that have serial - in fact its been iffy since about the Thinkpad 600 ! IRQ 7 for parallel is rarely used (and in fact we usually poll) IRQ 14/15 is wrong for ATA today as its AHCI based on modern boxes
And all the drivers you list are *cross platform* already.
> A bunch of these hardware devices we can get if someone connects up a > lpc superio chip.
To an x86 PC class system using some very traditional (and no longer valid) bits of behaviour.
> Even if sfi is never implemented on a platform where that kind of > hardware exists, the current sfi code is setup to coexist > simultaneously in the kernel with all of the infrastructure of other > platforms where those kinds of devices exist. Which means there can > be drivers compiled into your kernel that make assumptions about > special properties of the irqs 0-15.
That would be a driver bug. It would be bite other systems beyond the legacy PC. In the PC world its been unsafe since PnP BIOS let alone ACPI.
> With the current code you should get all of the remapping of the > gsi's out of the legacy irq space without needing to lift a finger, > and if someone later decides we need an irq override so we can have > an isa irq present on a weird embedded system on a chip the code will > be able to handle that easily.
There is only one reason to care about this - that is ISA bus devices with software IRQ steering registers for the ISA lines. Now that might just about be a real reason, but as former maintainer of both serial and IDE (and part time fixer of parport) I'd say the other reasons are bunkum.
Alan --
| |