From patchwork Sat Aug 20 00:48:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Al Stone X-Patchwork-Id: 9291489 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 80FD3607FF for ; Sat, 20 Aug 2016 00:48:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6CC482960A for ; Sat, 20 Aug 2016 00:48:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6197E2960E; Sat, 20 Aug 2016 00:48:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0EA832960A for ; Sat, 20 Aug 2016 00:48:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755810AbcHTAsU (ORCPT ); Fri, 19 Aug 2016 20:48:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43268 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754617AbcHTAsT (ORCPT ); Fri, 19 Aug 2016 20:48:19 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA6B2C00F1DB; Sat, 20 Aug 2016 00:48:18 +0000 (UTC) Received: from fidelio.ahs3.com (ovpn-116-175.phx2.redhat.com [10.3.116.175]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7K0mGwF014247; Fri, 19 Aug 2016 20:48:18 -0400 From: Al Stone To: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Cc: ahs3@redhat.com, "Rafael J . Wysocki" , Len Brown Subject: [PATCH v2 1/3] ACPI: fix incorrect counts returned by acpi_parse_entries_array() Date: Fri, 19 Aug 2016 18:48:11 -0600 Message-Id: <1471654093-6962-2-git-send-email-ahs3@redhat.com> In-Reply-To: <1471654093-6962-1-git-send-email-ahs3@redhat.com> References: <1471654093-6962-1-git-send-email-ahs3@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Sat, 20 Aug 2016 00:48:18 +0000 (UTC) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The static function acpi_parse_entries_array() is provided an array of type struct acpi_subtable_proc that has a callback function and a count. The count should reflect how many times the callback has been called. However, the current code only increments the 0th element of the array, regardless of the number of entries in the array, or which callback has been invoked. The result is that we know the total number of callbacks made but we cannot determine which callbacks were made, nor how often. The fix is to index into the array of structs and increment the proper counts. There is one place in the x86 code for acpi_parse_madt_lapic_entries() where the counts for each callback are used. If no LAPICs *and* no X2APICs are found, an ENODEV is supposed to be returned; as it stands, the count of X2APICs will always be zero, regardless of what is in the MADT. Should there be no LAPICs, ENODEV will be returned in error, if there are X2APICs in the MADT. Otherwise, there are no other functional consequences of the count being done as it currently is; all other uses simply check that the return value from acpi_parse_entries_array() or passed back via its callers is either non-zero, an error, or in one case just ignored. In future patches, I will also need these counts to be correct; I need to count the number of instances of subtables of certain types within the MADT to determine whether or not an ACPI IORT is required or not, and report when it is not present when it should be. Signed-off-by: Al Stone Cc: Rafael J. Wysocki Cc: Len Brown --- drivers/acpi/tables.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index fa6fd19..3e167b4 100644 --- a/drivers/acpi/tables.c +++ b/drivers/acpi/tables.c @@ -281,7 +281,7 @@ acpi_parse_entries_array(char *id, unsigned long table_size, proc[i].handler(entry, table_end)) return -EINVAL; - proc->count++; + proc[i].count++; break; } if (i != proc_num)