On Wednesday 04 January 2006 16:29, Matt Domsch wrote: > On Wed, Jan 04, 2006 at 03:36:03PM -0700, Alex Williamson wrote: > > On Wed, 2006-01-04 at 16:16 -0600, Matt Domsch wrote: > > > Andi Kleen has a patch in his x86_64 tree which enables the use > > > of i386 dmi_scan.c on x86_64. dmi_scan.c functions are being > > > used by the drivers/char/ipmi/ipmi_si_intf.c driver for > > > autodetecting the ports or memory spaces where the IPMI > > > controllers may be found. > > > > Can't this be done via ACPI/EFI? I'm really opposed to adding > > anything to ia64 that blindly picks memory ranges and starts > > scanning for magic legacy tables. If nothing else, this can be > > found via efi.smbios. Thanks, > > I'll redo this to use efi.smbios. Thanks for the tip.
The DMI scan looks like it's done in try_init_smbios(). But try_init_acpi() is done first. Since every ia64 machine has ACPI, I would think try_init_acpi() should be sufficient. Or do you have a machine that doesn't supply the SPMI table used by try_init_acpi()? Personally, I think try_init_acpi() should be re-done so it uses the normal acpi_bus_register_driver() mechanism, which would locate the IPMI device in the ACPI namespace. I don't think there's any need to rely on the SPMI, which is primarily there to support OS's that want to do IPMI stuff early in boot, before the ACPI machinery is ready. Bjorn ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
