Hi! > > firmwarekit-discuss <firmwarekit-discuss@xxxxxxxxxxx> (added to CC list) > > see: http://linuxfirmwarekit.org/ > > > > But if I understand this problem right, this won't be easy. > > The ACPI tables are just parsed with system ("iasl ...") and syntactical > > errors/warnings are printed out. > > I also thought about a test, interpreting the DSDT and read out values > > of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is > > not designed for that atm. You need to compile in most parts of the > > acpica code and parse and interpret DSDT/SSDT code yourself in the > > firmwarekit core or inside a plugin, then do a walk_namespace call or > > whatever to find the functions/parts you like to examine. This is a lot > > work and needs a proper design (providing an interface to plugins to let > > them easily check specific AML/ASL code). > > Furthermore, we don't really know what we're looking for. How can you > tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or > trying to power the machine off? Adding to the fun, many modern ATA > controller have more than one way to issue a command. Maybe we can > match accesses inside regions specified by PCI BARs.... :-( Hmmm... perhaps we should do it the other way. ACPI is allowed to touch the embedded controller, what else? Maybe we should warn as soon as API touches non-EC I/O port? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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
