)]}'
{
  "log": [
    {
      "commit": "3ed3bce846abc7ef460104b461cac793e41afe5e",
      "tree": "6db86a6cdfd3600db4e24cd91f53ba6f4f661280",
      "parents": [
        "10dbe196a8da6b3196881269c6639c0ec11c36cb"
      ],
      "author": {
        "name": "Matt Domsch",
        "email": "Matt_Domsch@dell.com",
        "time": "Sun Mar 26 01:37:03 2006 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Sun Mar 26 08:56:54 2006 -0800"
      },
      "message": "[PATCH] ia64: use i386 dmi_scan.c\n\nEnable DMI table parsing on ia64.\n\nAndi Kleen has a patch in his x86_64 tree which enables the use of i386\ndmi_scan.c on x86_64.  dmi_scan.c functions are being used by the\ndrivers/char/ipmi/ipmi_si_intf.c driver for autodetecting the ports or\nmemory spaces where the IPMI controllers may be found.\n\nThis patch adds equivalent changes for ia64 as to what is in the x86_64\ntree.  In addition, I reworked the DMI detection, such that on EFI-capable\nsystems, it uses the efi.smbios pointer to find the table, rather than\nbrute-force searching from 0xF0000.  On non-EFI systems, it continues the\nbrute-force search.\n\nMy test system, an Intel S870BN4 \u0027Tiger4\u0027, aka Dell PowerEdge 7250, with\nlatest BIOS, does not list the IPMI controller in the ACPI namespace, nor\ndoes it have an ACPI SPMI table.  Also note, currently shipping Dell x8xx\nEM64T servers don\u0027t have these either, so DMI is the only method for\nobtaining the address of the IPMI controller.\n\nSigned-off-by: Matt Domsch \u003cMatt_Domsch@dell.com\u003e\nAcked-by: \"Luck, Tony\" \u003ctony.luck@intel.com\u003e\nCc: Andi Kleen \u003cak@muc.de\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    }
  ]
}