All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Gaurav Kohli <gkohli@codeaurora.org>
Cc: <tglx@linutronix.de>, <linux-kernel@vger.kernel.org>,
	<linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH v0] irqchip/gic-v3: Avoid check of lpi configuration for  non existent cpu
Date: Thu, 05 Dec 2019 13:18:43 +0000	[thread overview]
Message-ID: <18011d088d5202339048ac5e3c224bb5@www.loen.fr> (raw)
In-Reply-To: <209f30c6-c03a-daeb-1f01-e03c489f41d8@codeaurora.org>

On 2019-12-05 13:01, Gaurav Kohli wrote:
> On 12/5/2019 6:17 PM, Marc Zyngier wrote:
>> Hi Gaurav,
>> On 2019-12-05 10:55, Gaurav Kohli wrote:
>>> As per GIC specification, we can configure gic for more no of cpus
>>> then the available cpus in the soc, But this can cause mem abort
>>> while iterating lpi region for non existent cpu as we don't map
>> Which LPI region? We're talking about RDs, right... Or does LPI mean
>> something other than GIC LPIs for you?
>>
>
> Yes RDs only.
>>> redistrubutor region for non-existent cpu.
>>>
>>> To avoid this issue, put one more check of valid mpidr.
>> Sorry, but I'm not sure I grasp your problem. Let me try and 
>> rephrase it:
>> - Your GIC is configured for (let's say) 8 CPUs, and your SoC has 
>> only 4.
> Yes, suppose gic is configured for 8 cpus but soc has only 4 cpus.
> Then in this case gic_iterate will iterate till it get TYPER_LAST.

And that's what is expected from the architecture.

>
> But as gic is configured for 8, So last bit sets in eight
> redistributor regions only.
>> - As part of the probing, the driver iterates on the RD regions and 
>> explodes
>>    because something isn't mapped?
>> That'd be a grave bug, but I believe the issue is somewhere else.
>
> There are 4 cpus present, that's why we have mapped 4 redistributor
> only, but during probe below function keeps iterating and give mem
> abort for 5th cpu.
>
> static void gic_update_vlpi_properties(void)
> {
>         gic_iterate_rdists(__gic_update_vlpi_properties);
>
> }
>
> We can solve this problem by mapping all eight redistributor in dt,
> but ideally code should also able to handle this and we can avoid
> mappin?

The whole point of DT is to describe the HW, all the HW, nothing but
the HW. This is what is expected by both the architecture and Linux.

So you have the solution already. Don't lie to the kernel, and 
everything
will be fine.

         M.
-- 
Jazz is not dead. It just smells funny...

  parent reply	other threads:[~2019-12-05 13:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-05 10:55 [PATCH v0] irqchip/gic-v3: Avoid check of lpi configuration for non existent cpu Gaurav Kohli
2019-12-05 12:47 ` Marc Zyngier
2019-12-05 13:01   ` Gaurav Kohli
     [not found]   ` <209f30c6-c03a-daeb-1f01-e03c489f41d8@codeaurora.org>
2019-12-05 13:18     ` Marc Zyngier [this message]
2019-12-06  8:45       ` Gaurav Kohli
     [not found]       ` <cfec6054-0ebe-f70b-b1a8-6c7bd7fc4450@codeaurora.org>
2019-12-06  8:54         ` Marc Zyngier
2019-12-09 20:55 ` kbuild test robot
2019-12-09 20:55   ` kbuild test robot
2019-12-10  0:39 ` kbuild test robot
2019-12-10  0:39   ` kbuild test robot

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=18011d088d5202339048ac5e3c224bb5@www.loen.fr \
    --to=maz@kernel.org \
    --cc=gkohli@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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.