On Thu, Oct 18, 2007 at 11:01:59PM -0400, Corey Osgood wrote:
I would mark those irq tables as broken and use acpi routing. You can dump the factory acpi tables using acpidump (or cat /proc/acpi/dsdt > somefile), then decompile them with iasl. Once you do that, you can look through them for "(_PRT)", which should be the routing table. At that point, if the tables are simple enough, you can just pull those out, or if they're deeply integrated you can use the entire dsdt. Note that there may be some legal issues with redistribution of acpi tables, although the linux acpi project (on sourceforge) distributes them regularly, so I'm not sure where the problem lies.
I'm not sure either (and I'm not a lawyer of course), but I'd refraid from distributing whole ACPI tables + AML code gathered via acpidump (my guess is that the AML code is the bigger problem, as it's "code" whereas the static tables are just a bunch of numbers/data items in a simple list, more or less).
Not sure if it's a problem indeed, but we shouldn't take the risk if we don't have to.
The alternative is to either have the _user_ use acpidump on his system (and we provide a generic ACPI framework which can deal with acpidump output, more on that later). This is similar to the VGA blob approach.
The other possibility is to construct a valid irq_table.c with the help of the _PRT info (no need for ACPI if all you want is a working irq_table.c).
Or, you can try to fix up irq_table.c with the help of the method Juergen described in http://linuxbios.org/Creating_Valid_IRQ_Tables, where I'm pretty much 100% sure that there's _no_ legal problem involved whatsoever.
Uwe.