From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5826635960736535075==" MIME-Version: 1.0 From: Ross Zwisler Subject: Re: [Devel] [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array() Date: Thu, 06 Jul 2017 16:22:00 -0600 Message-ID: <20170706222200.GA31795@linux.intel.com> In-Reply-To: CAJZ5v0gUA4d+NFqEdsXPVktXf+2AX9MurEQAiCFGxU_eaoYE5A@mail.gmail.com List-ID: To: devel@acpica.org --===============5826635960736535075== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 e= ach > > subtable has a standard ACPI subtable entry of type struct > > acpi_sutbable_header. This standard subtable header has a one byte len= gth > > followed by a one byte type. > > > > The HMAT subtables have to allow for a longer length so they have subta= ble > > 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 c= an > > 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(-) > > > > diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c > > index edb0c79..917f1cc 100644 > > --- a/drivers/acpi/numa.c > > +++ b/drivers/acpi/numa.c > > @@ -443,7 +443,7 @@ int __init acpi_numa_init(void) > > * So go over all cpu entries in SRAT to get apicid to node map= ping. > > */ > > > > - /* SRAT: Static Resource Affinity Table */ > > + /* SRAT: System Resource Affinity Table */ > > if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) { > > struct acpi_subtable_proc srat_proc[3]; > > > = > This change is unrelated to the rest of the patch. > = > Maybe send it separately? Sure, will do. > > 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_subta= ble_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 re= ad ?: 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 rea= d, but that being said if you feel strongly about it I'll make the change. --===============5826635960736535075==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Zwisler Subject: Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array() Date: Thu, 6 Jul 2017 16:22:00 -0600 Message-ID: <20170706222200.GA31795@linux.intel.com> References: <20170706215233.11329-1-ross.zwisler@linux.intel.com> <20170706215233.11329-3-ross.zwisler@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: "Rafael J. Wysocki" Cc: "Box, David E" , Dave Hansen , "Zheng, Lv" , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , "Rafael J. Wysocki" , "Anaczkowski, Lukasz" , "Moore, Robert" , ACPI Devel Maling List , "Odzioba, Lukasz" , "Schmauss, Erik" , Len Brown , Jerome Glisse , "devel-E0kO6a4B6psdnm+yROfE0A@public.gmane.org" , "Kogut, Jaroslaw" , Linux Memory Management List , Greg Kroah-Hartman , "Nachimuthu, Murugasamy" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Lahtinen, Joo List-Id: linux-acpi@vger.kernel.org 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(-) > > > > diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c > > index edb0c79..917f1cc 100644 > > --- a/drivers/acpi/numa.c > > +++ b/drivers/acpi/numa.c > > @@ -443,7 +443,7 @@ int __init acpi_numa_init(void) > > * So go over all cpu entries in SRAT to get apicid to node mapping. > > */ > > > > - /* SRAT: Static Resource Affinity Table */ > > + /* SRAT: System Resource Affinity Table */ > > if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) { > > struct acpi_subtable_proc srat_proc[3]; > > > > This change is unrelated to the rest of the patch. > > Maybe send it separately? Sure, will do. > > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A373A21CE73EE for ; Thu, 6 Jul 2017 15:20:21 -0700 (PDT) Date: Thu, 6 Jul 2017 16:22:00 -0600 From: Ross Zwisler Subject: Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array() Message-ID: <20170706222200.GA31795@linux.intel.com> References: <20170706215233.11329-1-ross.zwisler@linux.intel.com> <20170706215233.11329-3-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: "Rafael J. Wysocki" Cc: "Box, David E" , Dave Hansen , "Zheng, Lv" , "linux-nvdimm@lists.01.org" , "Rafael J. Wysocki" , Anaczkowski,, "Robert , ACPI Devel Maling List" , Odzioba,, "Erik , Len Brown" , Jerome Glisse , "devel@acpica.org" , "Kogut, Jaroslaw , Linux Memory Management List" , Greg Kroah-Hartman , "Nachimuthu, Murugasamy , Rafael J. Wysocki" , Linux Kernel Mailing List , "Lahtinen, Joonas , Andrew Morton , Tim Chen" List-ID: 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(-) > > > > diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c > > index edb0c79..917f1cc 100644 > > --- a/drivers/acpi/numa.c > > +++ b/drivers/acpi/numa.c > > @@ -443,7 +443,7 @@ int __init acpi_numa_init(void) > > * So go over all cpu entries in SRAT to get apicid to node mapping. > > */ > > > > - /* SRAT: Static Resource Affinity Table */ > > + /* SRAT: System Resource Affinity Table */ > > if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) { > > struct acpi_subtable_proc srat_proc[3]; > > > > This change is unrelated to the rest of the patch. > > Maybe send it separately? Sure, will do. > > 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. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f72.google.com (mail-pg0-f72.google.com [74.125.83.72]) by kanga.kvack.org (Postfix) with ESMTP id DA8A56B0279 for ; Thu, 6 Jul 2017 18:22:03 -0400 (EDT) Received: by mail-pg0-f72.google.com with SMTP id 13so16025806pgg.8 for ; Thu, 06 Jul 2017 15:22:03 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com. [192.55.52.88]) by mx.google.com with ESMTPS id k64si850655pge.371.2017.07.06.15.22.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 15:22:02 -0700 (PDT) Date: Thu, 6 Jul 2017 16:22:00 -0600 From: Ross Zwisler Subject: Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array() Message-ID: <20170706222200.GA31795@linux.intel.com> References: <20170706215233.11329-1-ross.zwisler@linux.intel.com> <20170706215233.11329-3-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: "Rafael J. Wysocki" Cc: Ross Zwisler , 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" 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(-) > > > > diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c > > index edb0c79..917f1cc 100644 > > --- a/drivers/acpi/numa.c > > +++ b/drivers/acpi/numa.c > > @@ -443,7 +443,7 @@ int __init acpi_numa_init(void) > > * So go over all cpu entries in SRAT to get apicid to node mapping. > > */ > > > > - /* SRAT: Static Resource Affinity Table */ > > + /* SRAT: System Resource Affinity Table */ > > if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) { > > struct acpi_subtable_proc srat_proc[3]; > > > > This change is unrelated to the rest of the patch. > > Maybe send it separately? Sure, will do. > > 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752737AbdGFWWF (ORCPT ); Thu, 6 Jul 2017 18:22:05 -0400 Received: from mga07.intel.com ([134.134.136.100]:14501 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751956AbdGFWWD (ORCPT ); Thu, 6 Jul 2017 18:22:03 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,319,1496127600"; d="scan'208";a="989780120" Date: Thu, 6 Jul 2017 16:22:00 -0600 From: Ross Zwisler To: "Rafael J. Wysocki" Cc: Ross Zwisler , 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" Subject: Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array() Message-ID: <20170706222200.GA31795@linux.intel.com> References: <20170706215233.11329-1-ross.zwisler@linux.intel.com> <20170706215233.11329-3-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(-) > > > > diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c > > index edb0c79..917f1cc 100644 > > --- a/drivers/acpi/numa.c > > +++ b/drivers/acpi/numa.c > > @@ -443,7 +443,7 @@ int __init acpi_numa_init(void) > > * So go over all cpu entries in SRAT to get apicid to node mapping. > > */ > > > > - /* SRAT: Static Resource Affinity Table */ > > + /* SRAT: System Resource Affinity Table */ > > if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) { > > struct acpi_subtable_proc srat_proc[3]; > > > > This change is unrelated to the rest of the patch. > > Maybe send it separately? Sure, will do. > > 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.