From: Hanjun Guo <guohanjun@huawei.com>
To: Mark Salter <msalter@redhat.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
Will Deacon <will.deacon@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH] ARM64 / SMP: Switch pr_err() to pr_debug() for disabled GICC entry
Date: Fri, 3 Jul 2015 09:18:42 +0800 [thread overview]
Message-ID: <5595E2F2.4070907@huawei.com> (raw)
In-Reply-To: <1435858716.24502.8.camel@redhat.com>
On 2015/7/3 1:38, Mark Salter wrote:
> On Wed, 2015-07-01 at 21:37 +0800, Hanjun Guo wrote:
>
>> It is normal that firmware presents GICC entry or entries (processors)
>> with disabled flag in ACPI MADT, taking a system of 16 cpus for example,
>> ACPI firmware may present 8 enabled first with another 8 cpus disabled
>> in MADT, the disabled cpus can be hot-added later.
>>
>> Firmware may also present more cpus than the hardware actually has, but
>> disabled the unused ones, and easily enable it when the hardware has such
>> cpus to make the firmware code scalable.
>>
>> So that's not an error for disabled cpus in MADT, we can switch
>> pr_err() to pr_debug() instead.
>>
> I agree with pr_debug instead of pr_err, but for hotplug to work
> I think we need to continue to parse the MADT instead of bailing
> out altogether, right? We need to know at init time how many
Yes, agreed :)
> possible cpus there are and that number never changes as cpus
> are plugged/unplugged. Right now, set_cpu_possible() only gets
> called if smp_cpu_setup() gets called and smp_cpu_setup() only
> gets called if the cpu is in the cpu_logical_map.
We need some extra work to make the physical CPU hotplug work
on ARM64.
Thanks
Hanjun
prev parent reply other threads:[~2015-07-03 1:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-01 13:37 [PATCH] ARM64 / SMP: Switch pr_err() to pr_debug() for disabled GICC entry Hanjun Guo
2015-07-01 17:02 ` Al Stone
2015-07-02 16:29 ` Catalin Marinas
2015-07-02 17:40 ` Mark Salter
2015-07-02 17:38 ` Mark Salter
2015-07-03 1:18 ` Hanjun Guo [this message]
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=5595E2F2.4070907@huawei.com \
--to=guohanjun@huawei.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=catalin.marinas@arm.com \
--cc=hanjun.guo@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=msalter@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).