Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756456AbbHZMnQ (ORCPT ); Wed, 26 Aug 2015 08:43:16 -0400 Received: from foss.arm.com ([217.140.101.70]:44923 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752311AbbHZMnN (ORCPT ); Wed, 26 Aug 2015 08:43:13 -0400 Message-ID: <55DDB45D.2030901@arm.com> Date: Wed, 26 Aug 2015 13:43:09 +0100 From: Marc Zyngier Organization: ARM Ltd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Lorenzo Pieralisi , "Anaczkowski, Lukasz" CC: "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" , "x86@kernel.org" , "jason@lakedaemon.net" , "rjw@rjwysocki.net" , "Brown, Len" , "pavel@ucw.cz" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , Yinghai Lu Subject: Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT References: <20150802134014.380415cd@arm.com> <1438626365-23709-1-git-send-email-lukasz.anaczkowski@intel.com> <1438626365-23709-2-git-send-email-lukasz.anaczkowski@intel.com> <55DD9838.20505@arm.com> <20150826114250.GA11863@red-moon> In-Reply-To: <20150826114250.GA11863@red-moon> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2282 Lines: 77 On 26/08/15 12:42, Lorenzo Pieralisi wrote: > Hi Lukasz, > > On Wed, Aug 26, 2015 at 11:43:04AM +0100, Marc Zyngier wrote: >> Hi Lukasz, >> >> On 26/08/15 08:04, Anaczkowski, Lukasz wrote: >>> On Monday, August 3, 2015 8:26 PM >>> Lukasz Anaczkowski wrote: >>> >>>> v2: Fixed ARM64 syntax error >>> >>> Hi Marc, >>> >>> Does this patch look ok now? > > No it does not, it seems to break arm64, I put together a fix > below. I do not think the way you handle the count increment > in acpi_parse_entries() is correct anyway, since you increment > it only if max_entries != 0, which changes mainline behaviour. Yeah, this is fundamentally flawed: - count is only incremented when max_entries != 0, as you noticed - With max_entries != 0, count now represent the sum of all matches Is that expected? - The proc iteration stops after the first match. Why? - The test for max_entries is done inside the proc loop. Why? I came up with the following patch that restores arm64 to a booting state. If the intention was to change the meaning of the acpi_parse_entries return value, then this should be documented and agreed upon. diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index 1217e41..f06327f 100644 --- a/drivers/acpi/tables.c +++ b/drivers/acpi/tables.c @@ -249,19 +249,24 @@ acpi_parse_entries(char *id, unsigned long table_size, while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) < table_end) { + bool match = false; + + if (max_entries && count >= max_entries) + break; for (i = 0; i < proc_num; i++) { if (entry->type != proc[i].id) continue; - if (max_entries && count++ >= max_entries) - continue; if (proc[i].handler(entry, table_end)) { proc[i].count = -EINVAL; return -EINVAL; } proc[i].count++; - break; + match = true; } + if (match) + count++; + /* * If entry->length is 0, break from this loop to avoid * infinite loop. Thanks, M. -- Jazz is not dead. It just smells funny... -- 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/