Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1398206 > unrolled thread

[PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type Jon Hunter <jonathanh@nvidia.com> - 2016-05-10 17:20 +0200
    Re: [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type Marc Zyngier <marc.zyngier@arm.com> - 2016-05-10 19:30 +0200
      Re: [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type Jon Hunter <jonathanh@nvidia.com> - 2016-05-10 20:10 +0200
        Re: [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type Jon Hunter <jonathanh@nvidia.com> - 2016-05-10 20:10 +0200

#1398206 — [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type

When setting the IRQ type we don't check the return value to see if it
is set correctly. Due to this, failures to set the IRQ type have gone
unnoticed and because these failures were not catastrophic have not had
an impact on the system.

Ideally, we should return an error if we fail to set the type, however,
this could cause non-catastrophic failures to prevent devices from
working. Therefore, for now add a warning so that any bad interrupt
configurations can be corrected.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
 kernel/irq/irqdomain.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 8798b6c9e945..09060072cc28 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -610,7 +610,8 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec *fwspec)
 	/* Set type if specified and different than the current one */
 	if (type != IRQ_TYPE_NONE &&
 	    type != irq_get_trigger_type(virq))
-		irq_set_irq_type(virq, type);
+		if (irq_set_irq_type(virq, type))
+			pr_warn("failed to set type for irq %d\n", virq);
 	return virq;
 }
 EXPORT_SYMBOL_GPL(irq_create_fwspec_mapping);
-- 
2.1.4

[toc] | [next] | [standalone]

#1398344

On 10/05/16 16:14, Jon Hunter wrote:
> When setting the IRQ type we don't check the return value to see if it
> is set correctly. Due to this, failures to set the IRQ type have gone
> unnoticed and because these failures were not catastrophic have not had
> an impact on the system.
> 
> Ideally, we should return an error if we fail to set the type, however,
> this could cause non-catastrophic failures to prevent devices from
> working. Therefore, for now add a warning so that any bad interrupt
> configurations can be corrected.
> 
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> ---
>  kernel/irq/irqdomain.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 8798b6c9e945..09060072cc28 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -610,7 +610,8 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec *fwspec)
>  	/* Set type if specified and different than the current one */
>  	if (type != IRQ_TYPE_NONE &&
>  	    type != irq_get_trigger_type(virq))
> -		irq_set_irq_type(virq, type);
> +		if (irq_set_irq_type(virq, type))
> +			pr_warn("failed to set type for irq %d\n", virq);

This warning triggers on all per-cpu interrupts, because
irq_set_irq_type() uses IRQ_GET_DESC_CHECK_GLOBAL and not
IRQ_GET_DESC_CHECK_PERCPU. Which sort of makes sense because the trigger
is per-cpu and not global. We'd need some similar check in
enable_percpu_irq, but at that stage, we've already lost the context
coming from the firmware.

Which only proves one thing: per-cpu interrupts have never been
configured on the allocation path, and we've been living pretty
dangerously so far. They do work (at least on ARM) because of the
following reasons:

1) the triggers are already configured (firmware, read-only...)
2) the handle_percpu_devid_irq handler doesn't distinguish between flows

It is probably broken on all other architectures, which kind of sucks.
At this point, I'm really tempted to drop this patch and to aim towards
something similar to what you had in patches 5 and 6 in your previous
series. I'll have a think tonight.

Thanks,

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

[toc] | [prev] | [next] | [standalone]

#1398372

On 10/05/16 18:25, Marc Zyngier wrote:
> On 10/05/16 16:14, Jon Hunter wrote:
>> When setting the IRQ type we don't check the return value to see if it
>> is set correctly. Due to this, failures to set the IRQ type have gone
>> unnoticed and because these failures were not catastrophic have not had
>> an impact on the system.
>>
>> Ideally, we should return an error if we fail to set the type, however,
>> this could cause non-catastrophic failures to prevent devices from
>> working. Therefore, for now add a warning so that any bad interrupt
>> configurations can be corrected.
>>
>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>> ---
>>  kernel/irq/irqdomain.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>> index 8798b6c9e945..09060072cc28 100644
>> --- a/kernel/irq/irqdomain.c
>> +++ b/kernel/irq/irqdomain.c
>> @@ -610,7 +610,8 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec *fwspec)
>>  	/* Set type if specified and different than the current one */
>>  	if (type != IRQ_TYPE_NONE &&
>>  	    type != irq_get_trigger_type(virq))
>> -		irq_set_irq_type(virq, type);
>> +		if (irq_set_irq_type(virq, type))
>> +			pr_warn("failed to set type for irq %d\n", virq);
> 
> This warning triggers on all per-cpu interrupts, because
> irq_set_irq_type() uses IRQ_GET_DESC_CHECK_GLOBAL and not
> IRQ_GET_DESC_CHECK_PERCPU. Which sort of makes sense because the trigger
> is per-cpu and not global. We'd need some similar check in
> enable_percpu_irq, but at that stage, we've already lost the context
> coming from the firmware.
> 
> Which only proves one thing: per-cpu interrupts have never been
> configured on the allocation path, and we've been living pretty
> dangerously so far. They do work (at least on ARM) because of the
> following reasons:
> 
> 1) the triggers are already configured (firmware, read-only...)
> 2) the handle_percpu_devid_irq handler doesn't distinguish between flows
> 
> It is probably broken on all other architectures, which kind of sucks.
> At this point, I'm really tempted to drop this patch and to aim towards
> something similar to what you had in patches 5 and 6 in your previous
> series. I'll have a think tonight.

OK. I will hold off on posting the other patches for the minute.

Cheers
Jon

[toc] | [prev] | [next] | [standalone]

#1398373

On 10/05/16 19:00, Jon Hunter wrote:
> 
> On 10/05/16 18:25, Marc Zyngier wrote:
>> On 10/05/16 16:14, Jon Hunter wrote:
>>> When setting the IRQ type we don't check the return value to see if it
>>> is set correctly. Due to this, failures to set the IRQ type have gone
>>> unnoticed and because these failures were not catastrophic have not had
>>> an impact on the system.
>>>
>>> Ideally, we should return an error if we fail to set the type, however,
>>> this could cause non-catastrophic failures to prevent devices from
>>> working. Therefore, for now add a warning so that any bad interrupt
>>> configurations can be corrected.
>>>
>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>>> ---
>>>  kernel/irq/irqdomain.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>>> index 8798b6c9e945..09060072cc28 100644
>>> --- a/kernel/irq/irqdomain.c
>>> +++ b/kernel/irq/irqdomain.c
>>> @@ -610,7 +610,8 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec *fwspec)
>>>  	/* Set type if specified and different than the current one */
>>>  	if (type != IRQ_TYPE_NONE &&
>>>  	    type != irq_get_trigger_type(virq))
>>> -		irq_set_irq_type(virq, type);
>>> +		if (irq_set_irq_type(virq, type))
>>> +			pr_warn("failed to set type for irq %d\n", virq);
>>
>> This warning triggers on all per-cpu interrupts, because
>> irq_set_irq_type() uses IRQ_GET_DESC_CHECK_GLOBAL and not
>> IRQ_GET_DESC_CHECK_PERCPU. Which sort of makes sense because the trigger
>> is per-cpu and not global. We'd need some similar check in
>> enable_percpu_irq, but at that stage, we've already lost the context
>> coming from the firmware.
>>
>> Which only proves one thing: per-cpu interrupts have never been
>> configured on the allocation path, and we've been living pretty
>> dangerously so far. They do work (at least on ARM) because of the
>> following reasons:
>>
>> 1) the triggers are already configured (firmware, read-only...)
>> 2) the handle_percpu_devid_irq handler doesn't distinguish between flows
>>
>> It is probably broken on all other architectures, which kind of sucks.
>> At this point, I'm really tempted to drop this patch and to aim towards
>> something similar to what you had in patches 5 and 6 in your previous
>> series. I'll have a think tonight.
> 
> OK. I will hold off on posting the other patches for the minute.

By the way, it is fine if you want to drop this one for now and just
include the other 10 in your pull request.

Cheers
Jon

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web