It may work by chance. All what the code in question guarantees is:
int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
{
*irq = gsi;
return 0;
}
int acpi_register_gsi(u32 gsi, int triggering, int polarity)
{
unsigned int irq;
unsigned int plat_gsi = gsi;
acpi_gsi_to_irq(plat_gsi, &irq);
return irq;
}
CONFIG_PCI is optional for the x86 platform. You could argue this is a
bug in acpi_register_gsi() and I tend to agree -- I think the existence of
the ELCR is implied for ACPI-compliant systems, though I am happy to be
corrected. The ACPI spec does not mention the register, but quotes:
"Existing industry standard register interfaces to: CMOS, PIC, PITs, ..."
Anyway, blindly attaching to an IRQ line is not a terribly good idea as
there may be an edge-triggered line from a device wired there after all.
For example many LPC SuperIO chips have configurable IRQ resources -- the
parallel port can use either IRQ5 or IRQ7 (but not both at a time). OTOH
IRQ6 may be free after all as floppy drives become rare. Only IRQ10 and
IRQ11 are probably safe to be assumed free in systems with no ISA slots,
but then again, I may have missed something. Hopefully there are no true
PCI-ISA bridges with the HPET implemented -- I have checked a couple of
datasheets for ACPI-compliant PCI-ISA bridges (such as the PIIX4) that I
have handy and none of them implements the HPET.
Good to know. Thanks for verifying this.
Maciej
--
