mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: linux-kernel@vger.kernel.org
Cc: f.fainelli@gmail.com, "kernelci.org bot" <bot@kernelci.org>,
	Russell King <linux@armlinux.org.uk>,
	wahrenst@gmx.net, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] ARM: dt: check MPIDR on MP devices built without SMP
Date: Mon, 18 Nov 2019 12:49:04 +0100	[thread overview]
Message-ID: <5abdcb0e0e1043a101f579ea65d07a1f6b91f896.camel@suse.de> (raw)
In-Reply-To: <20191004155232.17209-1-nsaenzjulienne@suse.de>

[-- Attachment #1: Type: text/plain, Size: 2864 bytes --]

On Fri, 2019-10-04 at 17:52 +0200, Nicolas Saenz Julienne wrote:
> On SMP builds, in order to properly link CPU devices with their
> respective DT nodes we start by matching the boot CPU. This is achieved
> by comparing the 'reg' property on each of the CPU DT nodes with the
> MPIDR. The association is necessary as to validate the whole CPU logical
> map, which ultimately links CPU devices and their DT nodes.
> 
> On setups built without SMP, no MPIDR read is performed. The only thing
> expected is for the 'reg' property in the CPU DT node to contain the
> value 0x0.
> 
> This causes problems on MP setups built without SMP. As their boot CPU
> DT node contains the relevant MPIDR as opposed to 0x0. No match is then
> possible. This causes troubles further down the line as drivers are
> unable to get the CPU's DT node.
> 
> Change the way we choose whether to get the MPIDR or not. On builds
> without SMP check the number of CPUs defined in DT. Anything > 1 means
> the MPIDR should be available and matched accordingly.
> 
> Note that if there was a rogue UP device exposing multiple active CPUs
> in its DT the possible outcomes depend on the ARM series. For example
> Cortex-A9 specifies that the MPIDR is returns 0x0 on UP devices. On the
> other hand ARM1176JZ's TRM doesn't define a MPIDR register and specifies
> that any unwarranted register access will raise an undefined exception.
> Overall, given the bogus DT, a reasonable outcome.
> 
> This was originally seen on a Raspberry Pi 2 built with bcm2835_defconfig.
> 
> Reported-by: "kernelci.org bot" <bot@kernelci.org>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Tested-by: Stefan Wahren <wahrenst@gmx.net>

ping :)

> ---
> 
> Changes since v1:
>   - Rewrite patch description
>   - Use of_get_available_child_count()
> 
> Note: kept Setfan's Tested-by as the changes only affect a corner case.
> 
>  arch/arm/kernel/devtree.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 39c978698406..cd11742d9bc2 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -74,7 +74,7 @@ void __init arm_dt_init_cpu_maps(void)
>  	struct device_node *cpu, *cpus;
>  	int found_method = 0;
>  	u32 i, j, cpuidx = 1;
> -	u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
> +	u32 mpidr = 0;
>  
>  	u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
>  	bool bootcpu_valid = false;
> @@ -83,6 +83,9 @@ void __init arm_dt_init_cpu_maps(void)
>  	if (!cpus)
>  		return;
>  
> +	if (is_smp() || of_get_available_child_count(cpus) > 1)
> +		mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +
>  	for_each_of_cpu_node(cpu) {
>  		const __be32 *cell;
>  		int prop_bytes;


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-11-18 11:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 15:52 Nicolas Saenz Julienne
2019-11-18 11:49 ` Nicolas Saenz Julienne [this message]
2019-11-18 12:55   ` Russell King - ARM Linux admin
2019-11-18 17:45     ` Nicolas Saenz Julienne

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=5abdcb0e0e1043a101f579ea65d07a1f6b91f896.camel@suse.de \
    --to=nsaenzjulienne@suse.de \
    --cc=bot@kernelci.org \
    --cc=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=wahrenst@gmx.net \
    /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

all inboxes | Powered by JetHome®