Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array()

2017-07-06 Thread Rafael J. Wysocki
On Fri, Jul 7, 2017 at 12:22 AM, Ross Zwisler wrote: > On Fri, Jul 07, 2017 at 12:13:54AM +0200, Rafael J. Wysocki wrote: >> On Thu, Jul 6, 2017 at 11:52 PM, Ross Zwisler >> wrote: >> > The current implementation of acpi_parse_entries_array() assumes that each >> > subtable has a standard ACPI su

Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array()

2017-07-06 Thread Ross Zwisler
On Fri, Jul 07, 2017 at 12:13:54AM +0200, Rafael J. Wysocki wrote: > On Thu, Jul 6, 2017 at 11:52 PM, Ross Zwisler > wrote: > > The current implementation of acpi_parse_entries_array() assumes that each > > subtable has a standard ACPI subtable entry of type struct > > acpi_sutbable_header. This

Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array()

2017-07-06 Thread Rafael J. Wysocki
On Thu, Jul 6, 2017 at 11:52 PM, Ross Zwisler wrote: > The current implementation of acpi_parse_entries_array() assumes that each > subtable has a standard ACPI subtable entry of type struct > acpi_sutbable_header. This standard subtable header has a one byte length > followed by a one byte type.

[RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array()

2017-07-06 Thread Ross Zwisler
The current implementation of acpi_parse_entries_array() assumes that each subtable has a standard ACPI subtable entry of type struct acpi_sutbable_header. This standard subtable header has a one byte length followed by a one byte type. The HMAT subtables have to allow for a longer length so they