All of lore.kernel.org
 help / color / mirror / Atom feed
From: zijun_hu <zijun_hu@zoho.com>
To: Marc Zyngier <marc.zyngier@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
Subject: Re: [PATCH 1/1] irqchip/gicv3: iterate over possible CPUs by for_each_possible_cpu()
Date: Fri, 15 Sep 2017 11:05:25 +0800	[thread overview]
Message-ID: <59BB4375.1030007@zoho.com> (raw)
In-Reply-To: <86o9qdqe7m.fsf@arm.com>

On 09/15/2017 03:20 AM, Marc Zyngier wrote:
> On Thu, Sep 14 2017 at  1:15:14 pm BST, zijun_hu <zijun_hu@zoho.com> wrote:
>> From: zijun_hu <zijun_hu@htc.com>
>>
>> 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 

  reply	other threads:[~2017-09-15  3:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-14  5:15 [PATCH 1/1] irqchip/gicv3: iterate over possible CPUs by for_each_possible_cpu() zijun_hu
2017-09-14 19:20 ` Marc Zyngier
2017-09-15  3:05   ` zijun_hu [this message]
2017-09-15 14:42     ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59BB4375.1030007@zoho.com \
    --to=zijun_hu@zoho.com \
    --cc=james.morse@arm.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=zijun_hu@htc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.