On Wed, 2015-11-18 at 16:28 -0500, Linda Knippers wrote: > On 11/18/2015 4:07 PM, Verma, Vishal L wrote: > > On Wed, 2015-11-18 at 12:54 -0500, Linda Knippers wrote: > > > Since commit 209851649dc4f7900a6bfe1de5e2640ab2c7d931, we no longer > > > see NVDIMM devices on our systems. The NFIT/_FIT processing at > > > initialization gets a table from _FIT but doesn't like it. > > > > > > When support for _FIT was added, the code presumed that the data > > > returned by the _FIT method is identical to the NFIT table, which > > > starts with an acpi_table_header. However, the _FIT is defined > > > to return a data in the format of a series of NFIT type structure > > > entries and as a method, has an acpi_object header rather tahn > > > an acpi_table_header. > > > > Hm, I couldn't find any reference to this in the spec - that NFIT will > > have the acpi_table_header but _FIT will have a different header - but > > I'm no ACPI expert - is this usual convention? Any pointers where I > > could look at? > > I'm no ACPI expert either so maybe Toshi or someone else will help me > here but according to the FW developer, the convention is that there is > no ACPI table header because you already know what the table is. map_mat_entry() handles _MAT for processor objects, which expects no MADT header table. Thanks, -Toshi > Also, if you look at the NFIT definition (table 5-126) , the definition > explicitly includes the APCI table header but the _FIT definition does not. > It just says it's a series of NFIT Types structure entries. > -- 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
