From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Stone Subject: Re: [PATCH 2/3] ACPI: fix acpi_parse_entries_array() so it traverses all subtables Date: Fri, 1 Jul 2016 15:55:43 -0600 Message-ID: <00e1e2ec-b7e1-606d-3faa-271560864d0e@redhat.com> References: <1467408081-7418-1-git-send-email-ahs3@redhat.com> <1467408081-7418-3-git-send-email-ahs3@redhat.com> <3b06c1f7-d1d1-f86a-ba3c-ef566af2f6db@redhat.com> Reply-To: ahs3@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mail-it0-f48.google.com ([209.85.214.48]:35302 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751900AbcGAVzp (ORCPT ); Fri, 1 Jul 2016 17:55:45 -0400 Received: by mail-it0-f48.google.com with SMTP id g127so28067426ith.0 for ; Fri, 01 Jul 2016 14:55:44 -0700 (PDT) In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: "Rafael J. Wysocki" Cc: ACPI Devel Maling List , Linux Kernel Mailing List , "Rafael J . Wysocki" , Len Brown On 07/01/2016 03:46 PM, Rafael J. Wysocki wrote: > On Fri, Jul 1, 2016 at 11:41 PM, Al Stone wrote: >> On 07/01/2016 03:32 PM, Rafael J. Wysocki wrote: >>> On Fri, Jul 1, 2016 at 11:21 PM, Al Stone wrote: >>>> Without this patch, the acpi_parse_entries_array() function will return >>>> the very first time there is any error found in either the array of >>>> callback functions or if one of the callbacks returns an non-zero value. >>>> However, the array of callbacks could still have valid entries further >>>> on in the array, or the callbacks may be able to process subsequent >>>> subtables without error. The change here makes the function consistent >>>> with its description so that it will properly return the sum of all >>>> matching entries for all proc handlers, instead of stopping abruptly >>>> as it does today. >>> >>> I'm not sure I follow. >>> >>> You seem to be saying that the function should process all of the >>> subtables etc even though errors have been found for some of them, but >>> it still will return an error in the end if there are any errors. How >>> exactly does it help to continue processing in case of an error, then? >> >> The use case I have in mind is to simply count all of the subtables of >> a certain type. If for some reason, the callback -- or any other callback >> -- fails, the traversal of all the subtables stops immediately. So, I >> could have two callbacks, and if the first one fails on the first subtable >> of its type, traversal stops. The count for the second callback will be >> zero which may or may not be correct. > > It will be zero, because the callback has not been invoked at all. > Why is this incorrect? > Because there could be additional subtables after the one causing a failure that the second callback could have counted; e.g., if the failure is on the first subtable of 20 in the MADT, the following 19 would be ignored, even if they were all the right subtype for the second callback. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com -----------------------------------