Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753939AbaKXPSZ (ORCPT ); Mon, 24 Nov 2014 10:18:25 -0500 Received: from mail-wi0-f170.google.com ([209.85.212.170]:60911 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752198AbaKXPSX (ORCPT ); Mon, 24 Nov 2014 10:18:23 -0500 Message-ID: <54734C37.1060208@linaro.org> Date: Mon, 24 Nov 2014 16:18:15 +0100 From: Tomasz Nowicki User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Rafael J. Wysocki" CC: Hanjun Guo , Catalin Marinas , Mark Rutland , Olof Johansson , Grant Likely , Will Deacon , Graeme Gregory , Arnd Bergmann , Sudeep Holla , Jon Masters , Jason Cooper , Marc Zyngier , Bjorn Helgaas , Daniel Lezcano , Mark Brown , Rob Herring , Robert Richter , Lv Zheng , Robert Moore , Lorenzo Pieralisi , Liviu Dudau , Randy Dunlap , Charles.Garcia-Tobin@arm.com, Kangkang.Shen@huawei.com, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org Subject: Re: [PATCH v5 03/18] ACPI / table: Count matched and successfully parsed entries without specifying max entries References: <1413553034-20956-1-git-send-email-hanjun.guo@linaro.org> <2301926.MWJ5MneAen@vostro.rjw.lan> <54734844.1070505@linaro.org> <1943415.qgIc2QypIM@vostro.rjw.lan> In-Reply-To: <1943415.qgIc2QypIM@vostro.rjw.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24.11.2014 16:37, Rafael J. Wysocki wrote: > On Monday, November 24, 2014 04:01:24 PM Tomasz Nowicki wrote: >> On 24.11.2014 16:16, Rafael J. Wysocki wrote: >>> On Monday, November 24, 2014 09:34:24 AM Tomasz Nowicki wrote: >>>> On 24.11.2014 02:45, Rafael J. Wysocki wrote: >>>>> On Friday, October 17, 2014 09:36:59 PM Hanjun Guo wrote: >>>>>> From: Tomasz Nowicki >>>>>> >>>>>> It is very useful to traverse all available table entries without max >>>>>> number of expected entries type. Current acpi_parse_entries() >>>>>> implementation gives that feature but it does not count those entries, >>>>>> it returns 0 instead, so fix it to count matched and successfully >>>>>> entries and return it. >>>>> >>>>> Hmm. I guess that the goal is for count to only be incremented when the >>>>> condition is satisfied entirely, while without the patch it may be incremented >>>>> even if that isn't the case. >>>> >>>> That would be our goal if patch would look like: >>>> - && (!max_entries || count++ < max_entries)) >>>> + && (!max_entries && count++ < max_entries)) { >>>> but then we can not walk through all available entries (with max_entries==0) >>> >>> No, that's not what I was trying to say. :-) >>> >>>>> >>>>> I'm not sure how that is related to the above paragraph, however. >>>>> >>>> >>>> Previous changelog is not clear, let me rewrite it: >>>> >>>> acpi_parse_entries() allows to traverse all available table entries (aka >>>> subtables) by passing max_entries parameter equal to 0. But for that use >>>> case acpi_parse_entries() does not inform caller how many entries were >>>> matched and for how many entries handler was run against. That patch is >>>> going to fix it. >>> >>> Do I understand correctly that count is only ever incremented by current code >>> if max_entries is different from 0? >> >> Right. Currently "count" is incremented only if max_entries > 0. > > So can you say that in the changelog, please? > > Something like: > > "acpi_parse_entries() allows to traverse all available table entries (aka > subtables) by passing max_entries parameter equal to 0, but since its count > variable is only incremented if max_entries is not 0, the function always > returns 0 for max_entries equal to 0. It would be more useful if it returned > the number of entries matched instead, so make it increment count in that > case too". > Sure, thanks. Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/