Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752905AbdGFWgT (ORCPT ); Thu, 6 Jul 2017 18:36:19 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:33242 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752327AbdGFWgR (ORCPT ); Thu, 6 Jul 2017 18:36:17 -0400 MIME-Version: 1.0 In-Reply-To: <20170706222200.GA31795@linux.intel.com> References: <20170706215233.11329-1-ross.zwisler@linux.intel.com> <20170706215233.11329-3-ross.zwisler@linux.intel.com> <20170706222200.GA31795@linux.intel.com> From: "Rafael J. Wysocki" Date: Fri, 7 Jul 2017 00:36:16 +0200 X-Google-Sender-Auth: QPkJR6lImk2Q5VtLljjMmXBy54E Message-ID: Subject: Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array() To: Ross Zwisler Cc: "Rafael J. Wysocki" , Linux Kernel Mailing List , "Anaczkowski, Lukasz" , "Box, David E" , "Kogut, Jaroslaw" , "Lahtinen, Joonas" , "Moore, Robert" , "Nachimuthu, Murugasamy" , "Odzioba, Lukasz" , "Rafael J. Wysocki" , "Rafael J. Wysocki" , "Schmauss, Erik" , "Verma, Vishal L" , "Zheng, Lv" , Andrew Morton , Dan Williams , Dave Hansen , Greg Kroah-Hartman , Jerome Glisse , Len Brown , Tim Chen , "devel@acpica.org" , ACPI Devel Maling List , Linux Memory Management List , "linux-nvdimm@lists.01.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2443 Lines: 65 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 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 have subtable >> > headers of type struct acpi_hmat_structure which has a 2 byte type and a 4 >> > byte length. >> > >> > Enhance the subtable parsing in acpi_parse_entries_array() so that it can >> > handle these new HMAT subtables. >> > >> > Signed-off-by: Ross Zwisler >> > --- >> > drivers/acpi/numa.c | 2 +- >> > drivers/acpi/tables.c | 52 ++++++++++++++++++++++++++++++++++++++++----------- >> > 2 files changed, 42 insertions(+), 12 deletions(-) [cut] >> > diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c >> > index ff42539..7979171 100644 >> > --- a/drivers/acpi/tables.c >> > +++ b/drivers/acpi/tables.c >> > @@ -218,6 +218,33 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header) >> > } >> > } >> > >> > +static unsigned long __init >> > +acpi_get_entry_type(char *id, void *entry) >> > +{ >> > + if (!strncmp(id, ACPI_SIG_HMAT, 4)) >> > + return ((struct acpi_hmat_structure *)entry)->type; >> > + else >> > + return ((struct acpi_subtable_header *)entry)->type; >> > +} >> >> I slightly prefer to use ? : in similar situations. > > Hmm..that becomes rather long, and seems complex for the already hard to read > ?: operator? Let's see, this: > > if (!strncmp(id, ACPI_SIG_HMAT, 4)) > return ((struct acpi_hmat_structure *)entry)->type; > else > return ((struct acpi_subtable_header *)entry)->type; > > becomes > > return strncmp(id, ACPI_SIG_HMAT, 4)) ? > ((struct acpi_subtable_header *)entry)->type : > ((struct acpi_hmat_structure *)entry)->type; > > Hmm...we only save one line, and I personally find that a lot harder to read, > but that being said if you feel strongly about it I'll make the change. Well, I said "slightly". :-) Thanks, Rafael