All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Kevin Hilman <khilman@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 02/17] irqchip/gic: WARN if setting the interrupt type for a PPI fails
Date: Thu, 5 May 2016 15:41:07 +0100	[thread overview]
Message-ID: <572B5B82.4040902@nvidia.com> (raw)
In-Reply-To: <20160505144025.50c02f3d@arm.com>


On 05/05/16 14:40, Marc Zyngier wrote:
> On Thu, 5 May 2016 14:22:06 +0100
> Jon Hunter <jonathanh@nvidia.com> wrote:
> 
>> Hi Marc,
>>
>> On 05/05/16 13:06, Marc Zyngier wrote:
>>> Hi Jon,
>>>
>>> On 04/05/16 17:25, Jon Hunter wrote:
>>>> Setting the interrupt type for private peripheral interrupts (PPIs) may
>>>> not be supported by a given GIC because it is IMPLEMENTATION DEFINED
>>>> whether this is allowed. There is no way to know if setting the type is
>>>> supported for a given GIC and so the value written is read back to
>>>> verify it matches the desired configuration. If it does not match then
>>>> an error is return.
>>>>
>>>> There are cases where the interrupt configuration read from firmware
>>>> (such as a device-tree blob), has been incorrect and hence
>>>> gic_configure_irq() has returned an error. This error has gone
>>>> undetected because the error code returned was ignored but the interrupt
>>>> still worked fine because the configuration for the interrupt could not
>>>> be overwritten.
>>>>
>>>> Given that this has done undetected and that failing to set the
>>>> configuration for a PPI may not be a catastrophic, don't return an error
>>>> but WARN if we fail to configure a PPI. This will allows us to fix up
>>>> any places in the kernel where we should be checking the return status
>>>> and maintain backward compatibility with firmware images that may have
>>>> incorrect PPI configurations.
>>>>
>>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>>>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>>> ---
>>>>  drivers/irqchip/irq-gic-common.c | 11 +++++++----
>>>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
>>>> index ffff5a45f1e3..9fa92a17225c 100644
>>>> --- a/drivers/irqchip/irq-gic-common.c
>>>> +++ b/drivers/irqchip/irq-gic-common.c
>>>> @@ -56,12 +56,15 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
>>>>  
>>>>  	/*
>>>>  	 * Write back the new configuration, and possibly re-enable
>>>> -	 * the interrupt. If we fail to write a new configuration,
>>>> -	 * return an error.
>>>> +	 * the interrupt. WARN if we fail to write a new configuration
>>>> +	 * and return an error if we failed to write the configuration
>>>> +	 * for an SPI. If we fail to write the configuration for a PPI
>>>> +	 * this is most likely because the GIC does not allow us to set
>>>> +	 * the configuration and so it is not a catastrophic failure.
>>>>  	 */
>>>>  	writel_relaxed(val, base + GIC_DIST_CONFIG + confoff);
>>>> -	if (readl_relaxed(base + GIC_DIST_CONFIG + confoff) != val)
>>>> -		ret = -EINVAL;
>>>> +	if (WARN_ON(readl_relaxed(base + GIC_DIST_CONFIG + confoff) != val))
>>>> +		ret = irq < 32 ? 0 : -EINVAL;
>>>>  
>>>>  	if (sync_access)
>>>>  		sync_access();
>>>>
>>>
>>> I'm going to slightly backpedal on that one:
>>>
>>> When running in non-secure mode, you can reconfigure secure interrupts
>>
>> Do you mean 'cannot'?
> 
> Yes, sorry.
> 
>>> (for obvious reasons). But you don't know which mode you're running in
>>> either. A typical example is the arch timer, which requests both secure
>>> and non-secure interrupts, because we cannot know which side of the CPU
>>> we're running on. In the non-secure case, we end-up with a splat that
>>> is rather undeserved.
>>
>> Yes seems sensible.
>>
>>> So I'm tempted to tone down the splat in the PPI case like this:
>>>
>>> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
>>> index 083c303..1605e42 100644
>>> --- a/drivers/irqchip/irq-gic-common.c
>>> +++ b/drivers/irqchip/irq-gic-common.c
>>> @@ -63,8 +63,17 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
>>>  	 * the configuration and so it is not a catastrophic failure.
>>>  	 */
>>>  	writel_relaxed(val, base + GIC_DIST_CONFIG + confoff);
>>> -	if (WARN_ON(readl_relaxed(base + GIC_DIST_CONFIG + confoff) != val))
>>> -		ret = irq < 32 ? 0 : -EINVAL;
>>> +	oldval = readl_relaxed(base + GIC_DIST_CONFIG + confoff);
>>> +	if (oldval != val) {
>>> +		if (irq < 32) {
>>> +			pr_warn("GIC: PPI%d is either secure or misconfigured\n",
>>> +				irq - 16);
>>> +			ret = 0;
>>> +		} else {
>>> +			WARN_ON(1);
>>> +			ret = -EINVAL;
>>> +		}
>>> +	}
>>>  
>>>  	if (sync_access)
>>>  		sync_access();
>>>
>>> Thoughts?
>>
>> That is fine with me. Do you want me to re-spin or do you want to apply
>> your change on top? However, before I re-spin would like to get your
>> thoughts on patches 13-17.
> 
> I can squash this into your own patch if you're OK with it. I'll reply
> to your other patches shortly, as I have a number of comments there.

Yes that is fine with me.

Cheers
Jon

WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jonathanh@nvidia.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Kevin Hilman <khilman@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	<linux-tegra@vger.kernel.org>, <linux-omap@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3 02/17] irqchip/gic: WARN if setting the interrupt type for a PPI fails
Date: Thu, 5 May 2016 15:41:07 +0100	[thread overview]
Message-ID: <572B5B82.4040902@nvidia.com> (raw)
In-Reply-To: <20160505144025.50c02f3d@arm.com>


On 05/05/16 14:40, Marc Zyngier wrote:
> On Thu, 5 May 2016 14:22:06 +0100
> Jon Hunter <jonathanh@nvidia.com> wrote:
> 
>> Hi Marc,
>>
>> On 05/05/16 13:06, Marc Zyngier wrote:
>>> Hi Jon,
>>>
>>> On 04/05/16 17:25, Jon Hunter wrote:
>>>> Setting the interrupt type for private peripheral interrupts (PPIs) may
>>>> not be supported by a given GIC because it is IMPLEMENTATION DEFINED
>>>> whether this is allowed. There is no way to know if setting the type is
>>>> supported for a given GIC and so the value written is read back to
>>>> verify it matches the desired configuration. If it does not match then
>>>> an error is return.
>>>>
>>>> There are cases where the interrupt configuration read from firmware
>>>> (such as a device-tree blob), has been incorrect and hence
>>>> gic_configure_irq() has returned an error. This error has gone
>>>> undetected because the error code returned was ignored but the interrupt
>>>> still worked fine because the configuration for the interrupt could not
>>>> be overwritten.
>>>>
>>>> Given that this has done undetected and that failing to set the
>>>> configuration for a PPI may not be a catastrophic, don't return an error
>>>> but WARN if we fail to configure a PPI. This will allows us to fix up
>>>> any places in the kernel where we should be checking the return status
>>>> and maintain backward compatibility with firmware images that may have
>>>> incorrect PPI configurations.
>>>>
>>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>>>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>>> ---
>>>>  drivers/irqchip/irq-gic-common.c | 11 +++++++----
>>>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
>>>> index ffff5a45f1e3..9fa92a17225c 100644
>>>> --- a/drivers/irqchip/irq-gic-common.c
>>>> +++ b/drivers/irqchip/irq-gic-common.c
>>>> @@ -56,12 +56,15 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
>>>>  
>>>>  	/*
>>>>  	 * Write back the new configuration, and possibly re-enable
>>>> -	 * the interrupt. If we fail to write a new configuration,
>>>> -	 * return an error.
>>>> +	 * the interrupt. WARN if we fail to write a new configuration
>>>> +	 * and return an error if we failed to write the configuration
>>>> +	 * for an SPI. If we fail to write the configuration for a PPI
>>>> +	 * this is most likely because the GIC does not allow us to set
>>>> +	 * the configuration and so it is not a catastrophic failure.
>>>>  	 */
>>>>  	writel_relaxed(val, base + GIC_DIST_CONFIG + confoff);
>>>> -	if (readl_relaxed(base + GIC_DIST_CONFIG + confoff) != val)
>>>> -		ret = -EINVAL;
>>>> +	if (WARN_ON(readl_relaxed(base + GIC_DIST_CONFIG + confoff) != val))
>>>> +		ret = irq < 32 ? 0 : -EINVAL;
>>>>  
>>>>  	if (sync_access)
>>>>  		sync_access();
>>>>
>>>
>>> I'm going to slightly backpedal on that one:
>>>
>>> When running in non-secure mode, you can reconfigure secure interrupts
>>
>> Do you mean 'cannot'?
> 
> Yes, sorry.
> 
>>> (for obvious reasons). But you don't know which mode you're running in
>>> either. A typical example is the arch timer, which requests both secure
>>> and non-secure interrupts, because we cannot know which side of the CPU
>>> we're running on. In the non-secure case, we end-up with a splat that
>>> is rather undeserved.
>>
>> Yes seems sensible.
>>
>>> So I'm tempted to tone down the splat in the PPI case like this:
>>>
>>> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
>>> index 083c303..1605e42 100644
>>> --- a/drivers/irqchip/irq-gic-common.c
>>> +++ b/drivers/irqchip/irq-gic-common.c
>>> @@ -63,8 +63,17 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
>>>  	 * the configuration and so it is not a catastrophic failure.
>>>  	 */
>>>  	writel_relaxed(val, base + GIC_DIST_CONFIG + confoff);
>>> -	if (WARN_ON(readl_relaxed(base + GIC_DIST_CONFIG + confoff) != val))
>>> -		ret = irq < 32 ? 0 : -EINVAL;
>>> +	oldval = readl_relaxed(base + GIC_DIST_CONFIG + confoff);
>>> +	if (oldval != val) {
>>> +		if (irq < 32) {
>>> +			pr_warn("GIC: PPI%d is either secure or misconfigured\n",
>>> +				irq - 16);
>>> +			ret = 0;
>>> +		} else {
>>> +			WARN_ON(1);
>>> +			ret = -EINVAL;
>>> +		}
>>> +	}
>>>  
>>>  	if (sync_access)
>>>  		sync_access();
>>>
>>> Thoughts?
>>
>> That is fine with me. Do you want me to re-spin or do you want to apply
>> your change on top? However, before I re-spin would like to get your
>> thoughts on patches 13-17.
> 
> I can squash this into your own patch if you're OK with it. I'll reply
> to your other patches shortly, as I have a number of comments there.

Yes that is fine with me.

Cheers
Jon

  reply	other threads:[~2016-05-05 14:41 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-04 16:25 [PATCH V3 00/17] Add support for Tegra210 AGIC Jon Hunter
2016-05-04 16:25 ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 01/17] irqchip/gic: Don't unnecessarily write the IRQ configuration Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 02/17] irqchip/gic: WARN if setting the interrupt type for a PPI fails Jon Hunter
2016-05-04 16:25   ` Jon Hunter
     [not found]   ` <1462379130-11742-3-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-05 12:06     ` Marc Zyngier
2016-05-05 12:06       ` Marc Zyngier
2016-05-05 13:22       ` Jon Hunter
2016-05-05 13:22         ` Jon Hunter
2016-05-05 13:40         ` Marc Zyngier
2016-05-05 13:40           ` Marc Zyngier
2016-05-05 14:41           ` Jon Hunter [this message]
2016-05-05 14:41             ` Jon Hunter
     [not found] ` <1462379130-11742-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-04 16:25   ` [PATCH V3 03/17] irqchip: Mask the non-type/sense bits when translating an IRQ Jon Hunter
2016-05-04 16:25     ` Jon Hunter
2016-05-04 16:25   ` [PATCH V3 16/17] irqchip/gic: Prepare for adding platform driver Jon Hunter
2016-05-04 16:25     ` Jon Hunter
     [not found]     ` <1462379130-11742-17-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-05 14:13       ` Marc Zyngier
2016-05-05 14:13         ` Marc Zyngier
     [not found]         ` <572B54F4.2080103-5wv7dgnIgG8@public.gmane.org>
2016-05-06 14:09           ` Jon Hunter
2016-05-06 14:09             ` Jon Hunter
     [not found]             ` <572CA5AF.7080504-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-06 14:27               ` Marc Zyngier
2016-05-06 14:27                 ` Marc Zyngier
2016-05-04 16:25 ` [PATCH V3 04/17] irqdomain: Fix handling of type settings for existing mappings Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 05/17] genirq: Look-up trigger type if not specified by caller Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 06/17] irqdomain: Don't set type when mapping an IRQ Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-09 12:23   ` Marc Zyngier
     [not found]     ` <5730813B.7060206-5wv7dgnIgG8@public.gmane.org>
2016-05-09 13:13       ` Jon Hunter
2016-05-09 13:13         ` Jon Hunter
     [not found]         ` <57308D0D.4080800-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-09 15:10           ` Marc Zyngier
2016-05-09 15:10             ` Marc Zyngier
     [not found]             ` <5730A867.9070504-5wv7dgnIgG8@public.gmane.org>
2016-05-09 15:44               ` Jon Hunter
2016-05-09 15:44                 ` Jon Hunter
     [not found]                 ` <5730B078.8090908-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-10 12:20                   ` Marc Zyngier
2016-05-10 12:20                     ` Marc Zyngier
2016-05-04 16:25 ` [PATCH V3 07/17] genirq: Ensure IRQ descriptor is valid when setting-up the IRQ Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 08/17] genirq: Add runtime power management support for IRQ chips Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 09/17] irqchip/gic: Don't initialise chip if mapping IO space fails Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 10/17] irqchip/gic: Remove static irq_chip definition for eoimode1 Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 11/17] irqchip/gic: Return an error if GIC initialisation fails Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 12/17] irqchip/gic: Pass GIC pointer to save/restore functions Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 13/17] irqchip/gic: Don't allow early initialisation if GIC requires RPM Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 14/17] irqchip/gic: Add helper function for configuring a GIC via device-tree Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 15/17] irqchip/gic: Split GIC init in preparation for platform driver Jon Hunter
2016-05-04 16:25   ` Jon Hunter
2016-05-04 16:25 ` [PATCH V3 17/17] irqchip/gic: Add platform driver for non-root GICs that require RPM Jon Hunter
2016-05-04 16:25   ` Jon Hunter

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=572B5B82.4040902@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=geert@linux-m68k.org \
    --cc=grygorii.strashko@ti.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jason@lakedaemon.net \
    --cc=khilman@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.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.