[lkml]   [2007]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/5][RFC] Physical PCI slot objects
    On Tuesday 13 November 2007 03:59:36 pm Kristen Carlson Accardi wrote:
    > On Tue, 13 Nov 2007 12:26:32 -0800 Greg KH <> wrote:
    > > And isn't there some other tool that dumps the raw ACPI tables? I
    > > thought the acpi developers used it all the time when debugging things
    > > with users.
    > There are - people should take a look at the Intel Linux Firmware Kit
    > for an example of how to parse ACPI tables in userspace - the code
    > is also GPL'd, so you are free to use it in another GPL application.
    > In many DSDTs I've seen, _SUN is hardcoded anyway and can be found
    > by reading the DSDT from userspace. This is what the firmwarekit
    > does to check for duplicate _SUN in one of it's tests.

    I see three relevant things in the firmware kit:

    1) ExecuteAmlMethod() in amlpoke/amlpoke.c. This uses
    /proc/acpi/hotkey/event_config to cause the kernel to
    execute an AML method. This looks similar to what dev_acpi
    does and is unsafe for the same reasons (the method may have
    side effects that interfere with kernel drivers). The kernel
    support for this was removed in 2.6.21:;a=commitdiff;h=5ee6edbcde4d3b14e4e03d4b331df1099a34aa8d

    2) execute_aml_method() in acpitable.c. Similar to above.

    3) parse_SUN_name() in SUN/SUN.c. This uses acpidump, acpixtract,
    and iasl -d to disassemble the DSDT and SSDTs, then looks for
    things like "Name (_SUN, 0x0000012C)". That works well if _SUN
    merely returns a constant, and many DSDTs do that.

    But _SUN can be implemented as a control method, and then we have
    a problem because we can't determine the _SUN value by inspecting
    the DSDT. We have to evaluate the method, and that may require
    operation regions, semaphores, etc., so it can only be done in the

    So I agree that the firmware kit has a clever hack that works on much
    existing x86 firmware, and it sounds like Tivoli might even rely on
    it. But I don't feel good about it, and it could easily break when
    some BIOS writer needs to make _SUN slightly more complicated.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-11-14 18:41    [W:0.021 / U:8.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site