Correct, the parseresource code really should look for IRQ/MEM, but I haven't yet seen any ACPI namespaces that use memory or IRQ resources with IPI0001 for testing. (I have a huge collection of DSDTs from my OpenBSD work). --jordan hargrave Dell Enterprise Linux Engineering -----Original Message----- From: Bjorn Helgaas [mailto:bjorn.helgaas@xxxxxx] Sent: Mon 2/26/2007 1:32 PM To: Hargrave, Jordan Cc: Domsch, Matt; minyard@xxxxxxx; alexey.y.starikovskiy@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; openipmi-developer@xxxxxxxxxxxxxxxxxxxxx; lenb@xxxxxxxxxx Subject: Re: [Openipmi-developer] acpi_find_bmc() and acpi_get_table() On Monday 26 February 2007 11:30, Jordan_Hargrave@xxxxxxxx wrote: > Here is the patch (RHEL5 base code) I've been testing that detects > the ACPI namespace object. I like this approach a lot. Shouldn't acpi_ipmi_getresource() also look for IRQ descriptors? The existing code that looks at the SPMI table can handle either GPEs or regular IOxAPIC interrupts (i.e., a GSI). You might also want to look for memory address ranges as well as IO ranges. I wish you could use pnp_register_driver() instead of acpi_bus_register_driver(). That would let you get rid of all the _CRS parsing. But I forgot that IPMI devices often use GPEs instead of regular interrupts, and GPEs require a different path (acpi_install_gpe_handler() instead of request_irq(), etc), so I guess you're stuck with grubbing through _CRS by hand. Plus, it looks like you need the _IFT thing to figure out what type of interface it is. It might have been nicer if there were separate PNP IDs for KCS vs SMIC vs BT. But that's water under the bridge. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
