Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751900AbdIODFy (ORCPT ); Thu, 14 Sep 2017 23:05:54 -0400 Received: from sender-pp-091.zoho.com ([135.84.80.236]:25036 "EHLO sender-pp-091.zoho.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751698AbdIODFx (ORCPT ); Thu, 14 Sep 2017 23:05:53 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:cc:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=Ijguqic7WGXJQ5d0MueRdluR8LOTcVLF91h1GlS6X6S+3zBDhOgVt5A8bEAW7PgP+RdqrB5BcZH4 IGxcBn0pKoSGW3/0VA7/fg2lH2Zs2gXQHlpQvSX/gn0YbAOy7n2c Subject: Re: [PATCH 1/1] irqchip/gicv3: iterate over possible CPUs by for_each_possible_cpu() To: Marc Zyngier References: <59BA1062.1010406@zoho.com> <86o9qdqe7m.fsf@arm.com> Cc: linux-kernel@vger.kernel.org, zijun_hu@htc.com, tglx@linutronix.de, jason@lakedaemon.net, james.morse@arm.com, sudeep.holla@arm.com From: zijun_hu Message-ID: <59BB4375.1030007@zoho.com> Date: Fri, 15 Sep 2017 11:05:25 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <86o9qdqe7m.fsf@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ZohoMailClient: External Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1584 Lines: 55 On 09/15/2017 03:20 AM, Marc Zyngier wrote: > On Thu, Sep 14 2017 at 1:15:14 pm BST, zijun_hu wrote: >> From: zijun_hu >> >> get_cpu_number() doesn't use existing helper to iterate over possible >> CPUs, so error happens in case of discontinuous @cpu_possible_mask >> such as 0b11110001. > > Do you have an example of such a situation? Your patch is definitely an > improvement, but I'd like to understand how you get there... > > Thanks, > > M. > a few conditions which maybe result in discontiguous @cpu_possible_mask are noticed and considered of by ARM64 init code as indicated by bellow code segments: in arch/arm64/kernel/smp.c : void __init smp_init_cpus(void) { ...... /* * We need to set the cpu_logical_map entries before enabling * the cpus so that cpu processor description entries (DT cpu nodes * and ACPI MADT entries) can be retrieved by matching the cpu hwid * with entries in cpu_logical_map while initializing the cpus. * If the cpu set-up fails, invalidate the cpu_logical_map entry. */ for (i = 1; i < nr_cpu_ids; i++) { if (cpu_logical_map(i) != INVALID_HWID) { if (smp_cpu_setup(i)) cpu_logical_map(i) = INVALID_HWID; } } ...... } /* * Initialize cpu operations for a logical cpu and * set it in the possible mask on success */ static int __init smp_cpu_setup(int cpu) { if (cpu_read_ops(cpu)) return -ENODEV; if (cpu_ops[cpu]->cpu_init(cpu)) return -ENODEV; set_cpu_possible(cpu, true); return 0; } i browses GICv3 drivers code and notice that a little weird code segments