Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Marc Zyngier]

On 18/09/16 11:26, Geert Uytterhoeven wrote:
> Hi Marc,
> 
> On Fri, Sep 16, 2016 at 9:51 AM, Marc Zyngier <marc.zyng...@arm.com> wrote:
>> On 16/09/16 00:02, Alban Browaeys wrote:
>>> Le mercredi 14 septembre 2016 à 21:25 +0200, Geert Uytterhoeven a
>>> écrit :
>>>> JFYI, with v4.8-rc6 I'm seeing
>>>>
>>>>     genirq: Setting trigger mode 0 for irq 11 failed
>>>> (txx9_irq_set_type+0x0/0xb8)
>>>>
>>>> on rbtx4927. This did not happen with v4.8-rc3.
>>>
>>> txx9_irq_set_type receives a type IRQ_TYPE_NONE from the call to
>>> __irq_set_trigger added in:
>>> 1e12c4a939 ("genirq: Correctly configure the trigger on chained interrupts")
> 
> Yep, that's the commit that introduced the issue.
> 
>>> This patch is a regression fix for :
>>>
>>> Desc: irqdomain: Don't set type when mapping an IRQ breaks nexus7 gpio 
>>> buttons
>>> Repo: 2016-07-30 https://marc.info/?l=linux-kernel=146985356305280=2
>>>
>>> I am seeing this on arm odroid u2 devicetree :
>>> genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x64)
>>
>> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
>> Can you point me to the various DTs and their failing interrupts?
> 
> Rbtx4927 does not use DT. The issue is triggered during:
> 
> irq_set_chained_handler(RBTX4927_IRQ_IOCINT, handle_simple_irq);
> 
> in arch/mips/txx9/rbtx4927/irq.c:toshiba_rbtx4927_irq_ioc_init(),
> which is inlined into rbtx4927_irq_setup().

Right. Vintage stuff ;-). It is odd that there is not handling of
interrupt trigger at all, but maybe the HW doesn't support it
(everything looks level).

> 
>> Also, can you please give the following patch a go and let me know
>> if that fixes the issue (I'm interested in the potential warning here).
>>
>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
>> index 6373890..8422779 100644
>> --- a/kernel/irq/chip.c
>> +++ b/kernel/irq/chip.c
>> @@ -820,6 +820,8 @@ __irq_do_set_handler(struct irq_desc *desc, 
>> irq_flow_handler_t handle,
>> desc->name = name;
>>
>> if (handle != handle_bad_irq && is_chained) {
>> +   unsigned int type = irqd_get_trigger_type(>irq_data);
>> +
>> /*
>>  * We're about to start this interrupt immediately,
>>  * hence the need to set the trigger configuration.
>> @@ -828,8 +830,10 @@ __irq_do_set_handler(struct irq_desc *desc, 
>> irq_flow_handler_t handle,
>>  * chained interrupt. Reset it immediately because we
>>  * do know better.
>>  */
>> -   __irq_set_trigger(desc, 
>> irqd_get_trigger_type(>irq_data));
>> -   desc->handle_irq = handle;
>> +   if (!(WARN_ON(type == IRQ_TYPE_NONE))) {
>> +   __irq_set_trigger(desc, type);
>> +   desc->handle_irq = handle;
>> +   }
>>
>> irq_settings_set_noprobe(desc);
>> irq_settings_set_norequest(desc);
> 
> This indeed makes the issue go away:
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 
> __irq_do_set_handler+0x144/0x1b4
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.8.0-rc6-rbtx4927-01162-g1596ef0280a363ac-dirty #50
> Stack :  1000 000b 0004 80453f47 804542d8 80429ff8 
> 
>  804a36c8 0341 80789384 01e0 803c70b0 8014a19c 80460ac8 
> 80460acc
>  804314ec  8042f408 80451d94 80789384 80173624 803c70b0 
> 8014a19c
>  0007 09e0      
> 000
> 
>         
> 
>  ...
> Call Trace:
> [<8010abf0>] show_stack+0x50/0x84
> [<8012100c>] __warn+0xe4/0x118
> [<80121098>] warn_slowpath_null+0x1c/0x28
> [<8014f7a0>] __irq_do_set_handler+0x144/0x1b4
> [<8014f860>] __irq_set_handler+0x50/0x7c
> [<804740ac>] tx4927_irq_init+0x34/0xa8
> [<80475e9c>] rbtx4927_irq_setup+0x30/0xd0
> [<8046e9c0>] start_kernel+0x288/0x450
> 
> ---[ end trace  ]---
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 
> __irq_do_set_handler+0x144/0x1b4
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Tainted: GW
> 4.8.0-rc6-rbtx4927-01162-g1596ef0280a363ac-dirty #50

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Marc Zyngier]

On 18/09/16 11:26, Geert Uytterhoeven wrote:
> Hi Marc,
> 
> On Fri, Sep 16, 2016 at 9:51 AM, Marc Zyngier  wrote:
>> On 16/09/16 00:02, Alban Browaeys wrote:
>>> Le mercredi 14 septembre 2016 à 21:25 +0200, Geert Uytterhoeven a
>>> écrit :
>>>> JFYI, with v4.8-rc6 I'm seeing
>>>>
>>>> genirq: Setting trigger mode 0 for irq 11 failed
>>>> (txx9_irq_set_type+0x0/0xb8)
>>>>
>>>> on rbtx4927. This did not happen with v4.8-rc3.
>>>
>>> txx9_irq_set_type receives a type IRQ_TYPE_NONE from the call to
>>> __irq_set_trigger added in:
>>> 1e12c4a939 ("genirq: Correctly configure the trigger on chained interrupts")
> 
> Yep, that's the commit that introduced the issue.
> 
>>> This patch is a regression fix for :
>>>
>>> Desc: irqdomain: Don't set type when mapping an IRQ breaks nexus7 gpio 
>>> buttons
>>> Repo: 2016-07-30 https://marc.info/?l=linux-kernel=146985356305280=2
>>>
>>> I am seeing this on arm odroid u2 devicetree :
>>> genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x64)
>>
>> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
>> Can you point me to the various DTs and their failing interrupts?
> 
> Rbtx4927 does not use DT. The issue is triggered during:
> 
> irq_set_chained_handler(RBTX4927_IRQ_IOCINT, handle_simple_irq);
> 
> in arch/mips/txx9/rbtx4927/irq.c:toshiba_rbtx4927_irq_ioc_init(),
> which is inlined into rbtx4927_irq_setup().

Right. Vintage stuff ;-). It is odd that there is not handling of
interrupt trigger at all, but maybe the HW doesn't support it
(everything looks level).

> 
>> Also, can you please give the following patch a go and let me know
>> if that fixes the issue (I'm interested in the potential warning here).
>>
>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
>> index 6373890..8422779 100644
>> --- a/kernel/irq/chip.c
>> +++ b/kernel/irq/chip.c
>> @@ -820,6 +820,8 @@ __irq_do_set_handler(struct irq_desc *desc, 
>> irq_flow_handler_t handle,
>> desc->name = name;
>>
>> if (handle != handle_bad_irq && is_chained) {
>> +   unsigned int type = irqd_get_trigger_type(>irq_data);
>> +
>> /*
>>  * We're about to start this interrupt immediately,
>>  * hence the need to set the trigger configuration.
>> @@ -828,8 +830,10 @@ __irq_do_set_handler(struct irq_desc *desc, 
>> irq_flow_handler_t handle,
>>  * chained interrupt. Reset it immediately because we
>>  * do know better.
>>  */
>> -   __irq_set_trigger(desc, 
>> irqd_get_trigger_type(>irq_data));
>> -   desc->handle_irq = handle;
>> +   if (!(WARN_ON(type == IRQ_TYPE_NONE))) {
>> +   __irq_set_trigger(desc, type);
>> +   desc->handle_irq = handle;
>> +   }
>>
>> irq_settings_set_noprobe(desc);
>> irq_settings_set_norequest(desc);
> 
> This indeed makes the issue go away:
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 
> __irq_do_set_handler+0x144/0x1b4
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.8.0-rc6-rbtx4927-01162-g1596ef0280a363ac-dirty #50
> Stack :  1000 000b 0004 80453f47 804542d8 80429ff8 
> 
>  804a36c8 0341 80789384 01e0 803c70b0 8014a19c 80460ac8 
> 80460acc
>  804314ec  8042f408 80451d94 80789384 80173624 803c70b0 
> 8014a19c
>  0007 09e0      
> 000
> 
>         
> 
>  ...
> Call Trace:
> [<8010abf0>] show_stack+0x50/0x84
> [<8012100c>] __warn+0xe4/0x118
> [<80121098>] warn_slowpath_null+0x1c/0x28
> [<8014f7a0>] __irq_do_set_handler+0x144/0x1b4
> [<8014f860>] __irq_set_handler+0x50/0x7c
> [<804740ac>] tx4927_irq_init+0x34/0xa8
> [<80475e9c>] rbtx4927_irq_setup+0x30/0xd0
> [<8046e9c0>] start_kernel+0x288/0x450
> 
> ---[ end trace  ]---
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 
> __irq_do_set_handler+0x144/0x1b4
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Tainted: GW
> 4.8.0-rc6-rbtx4927-01162-g1596ef0280a363ac-dirty #50
> Stack :  1

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Geert Uytterhoeven]

Hi Marc,

On Fri, Sep 16, 2016 at 9:51 AM, Marc Zyngier <marc.zyng...@arm.com> wrote:
> On 16/09/16 00:02, Alban Browaeys wrote:
>> Le mercredi 14 septembre 2016 à 21:25 +0200, Geert Uytterhoeven a
>> écrit :
>>> JFYI, with v4.8-rc6 I'm seeing
>>>
>>> genirq: Setting trigger mode 0 for irq 11 failed
>>> (txx9_irq_set_type+0x0/0xb8)
>>>
>>> on rbtx4927. This did not happen with v4.8-rc3.
>>
>> txx9_irq_set_type receives a type IRQ_TYPE_NONE from the call to
>> __irq_set_trigger added in:
>> 1e12c4a939 ("genirq: Correctly configure the trigger on chained interrupts")

Yep, that's the commit that introduced the issue.

>> This patch is a regression fix for :
>>
>> Desc: irqdomain: Don't set type when mapping an IRQ breaks nexus7 gpio 
>> buttons
>> Repo: 2016-07-30 https://marc.info/?l=linux-kernel=146985356305280=2
>>
>> I am seeing this on arm odroid u2 devicetree :
>> genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x64)
>
> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
> Can you point me to the various DTs and their failing interrupts?

Rbtx4927 does not use DT. The issue is triggered during:

irq_set_chained_handler(RBTX4927_IRQ_IOCINT, handle_simple_irq);

in arch/mips/txx9/rbtx4927/irq.c:toshiba_rbtx4927_irq_ioc_init(),
which is inlined into rbtx4927_irq_setup().

> Also, can you please give the following patch a go and let me know
> if that fixes the issue (I'm interested in the potential warning here).
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 6373890..8422779 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -820,6 +820,8 @@ __irq_do_set_handler(struct irq_desc *desc, 
> irq_flow_handler_t handle,
> desc->name = name;
>
> if (handle != handle_bad_irq && is_chained) {
> +   unsigned int type = irqd_get_trigger_type(>irq_data);
> +
> /*
>  * We're about to start this interrupt immediately,
>  * hence the need to set the trigger configuration.
> @@ -828,8 +830,10 @@ __irq_do_set_handler(struct irq_desc *desc, 
> irq_flow_handler_t handle,
>  * chained interrupt. Reset it immediately because we
>  * do know better.
>  */
> -   __irq_set_trigger(desc, 
> irqd_get_trigger_type(>irq_data));
> -   desc->handle_irq = handle;
> +   if (!(WARN_ON(type == IRQ_TYPE_NONE))) {
> +   __irq_set_trigger(desc, type);
> +   desc->handle_irq = handle;
> +   }
>
> irq_settings_set_noprobe(desc);
> irq_settings_set_norequest(desc);

This indeed makes the issue go away:

[ cut here ]
WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 __irq_do_set_handler+0x144/0x1b4
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted
4.8.0-rc6-rbtx4927-01162-g1596ef0280a363ac-dirty #50
Stack :  1000 000b 0004 80453f47 804542d8 80429ff8 
 804a36c8 0341 80789384 01e0 803c70b0 8014a19c 80460ac8 80460acc
 804314ec  8042f408 80451d94 80789384 80173624 803c70b0 8014a19c
 0007 09e0      000

        
 ...
Call Trace:
[<8010abf0>] show_stack+0x50/0x84
[<8012100c>] __warn+0xe4/0x118
[<80121098>] warn_slowpath_null+0x1c/0x28
[<8014f7a0>] __irq_do_set_handler+0x144/0x1b4
[<8014f860>] __irq_set_handler+0x50/0x7c
[<804740ac>] tx4927_irq_init+0x34/0xa8
[<80475e9c>] rbtx4927_irq_setup+0x30/0xd0
[<8046e9c0>] start_kernel+0x288/0x450

---[ end trace  ]---
[ cut here ]
WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 __irq_do_set_handler+0x144/0x1b4
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Tainted: GW
4.8.0-rc6-rbtx4927-01162-g1596ef0280a363ac-dirty #50
Stack :  1400 0009 0004 80453f47 804542d8 80429ff8 
 804a36c8 0341 80789384 01e0 803c70b0 8014a19c 80460ac8 80460acc
 804314ec  8042f408 80451dac 80789384 80173624 803c70b0 8014a19c
  0f00      
        
 ...
Call Trace:
[<8010abf0>] show_stack+0x50/0x84
[<8012100c>] __warn+0xe4/0x118
[<80121098>] warn_slowpath_null+0x1c/0x28
[<8014f7a0>] __irq_do_set_handler+0x144/0x1b4
[<8014f860>] __irq_set_handler+0x50/0x7c
[<80475f18>] rb

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Geert Uytterhoeven]

Hi Marc,

On Fri, Sep 16, 2016 at 9:51 AM, Marc Zyngier  wrote:
> On 16/09/16 00:02, Alban Browaeys wrote:
>> Le mercredi 14 septembre 2016 à 21:25 +0200, Geert Uytterhoeven a
>> écrit :
>>> JFYI, with v4.8-rc6 I'm seeing
>>>
>>>     genirq: Setting trigger mode 0 for irq 11 failed
>>> (txx9_irq_set_type+0x0/0xb8)
>>>
>>> on rbtx4927. This did not happen with v4.8-rc3.
>>
>> txx9_irq_set_type receives a type IRQ_TYPE_NONE from the call to
>> __irq_set_trigger added in:
>> 1e12c4a939 ("genirq: Correctly configure the trigger on chained interrupts")

Yep, that's the commit that introduced the issue.

>> This patch is a regression fix for :
>>
>> Desc: irqdomain: Don't set type when mapping an IRQ breaks nexus7 gpio 
>> buttons
>> Repo: 2016-07-30 https://marc.info/?l=linux-kernel=146985356305280=2
>>
>> I am seeing this on arm odroid u2 devicetree :
>> genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x64)
>
> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
> Can you point me to the various DTs and their failing interrupts?

Rbtx4927 does not use DT. The issue is triggered during:

irq_set_chained_handler(RBTX4927_IRQ_IOCINT, handle_simple_irq);

in arch/mips/txx9/rbtx4927/irq.c:toshiba_rbtx4927_irq_ioc_init(),
which is inlined into rbtx4927_irq_setup().

> Also, can you please give the following patch a go and let me know
> if that fixes the issue (I'm interested in the potential warning here).
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 6373890..8422779 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -820,6 +820,8 @@ __irq_do_set_handler(struct irq_desc *desc, 
> irq_flow_handler_t handle,
> desc->name = name;
>
> if (handle != handle_bad_irq && is_chained) {
> +   unsigned int type = irqd_get_trigger_type(>irq_data);
> +
> /*
>  * We're about to start this interrupt immediately,
>  * hence the need to set the trigger configuration.
> @@ -828,8 +830,10 @@ __irq_do_set_handler(struct irq_desc *desc, 
> irq_flow_handler_t handle,
>  * chained interrupt. Reset it immediately because we
>  * do know better.
>  */
> -   __irq_set_trigger(desc, 
> irqd_get_trigger_type(>irq_data));
> -   desc->handle_irq = handle;
> +   if (!(WARN_ON(type == IRQ_TYPE_NONE))) {
> +   __irq_set_trigger(desc, type);
> +   desc->handle_irq = handle;
> +   }
>
> irq_settings_set_noprobe(desc);
> irq_settings_set_norequest(desc);

This indeed makes the issue go away:

[ cut here ]
WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 __irq_do_set_handler+0x144/0x1b4
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted
4.8.0-rc6-rbtx4927-01162-g1596ef0280a363ac-dirty #50
Stack :  1000 000b 0004 80453f47 804542d8 80429ff8 
 804a36c8 0341 80789384 01e0 803c70b0 8014a19c 80460ac8 80460acc
 804314ec  8042f408 80451d94 80789384 80173624 803c70b0 8014a19c
 0007 09e0      000

        
 ...
Call Trace:
[<8010abf0>] show_stack+0x50/0x84
[<8012100c>] __warn+0xe4/0x118
[<80121098>] warn_slowpath_null+0x1c/0x28
[<8014f7a0>] __irq_do_set_handler+0x144/0x1b4
[<8014f860>] __irq_set_handler+0x50/0x7c
[<804740ac>] tx4927_irq_init+0x34/0xa8
[<80475e9c>] rbtx4927_irq_setup+0x30/0xd0
[<8046e9c0>] start_kernel+0x288/0x450

---[ end trace  ]---
[ cut here ]
WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 __irq_do_set_handler+0x144/0x1b4
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Tainted: GW
4.8.0-rc6-rbtx4927-01162-g1596ef0280a363ac-dirty #50
Stack :  1400 0009 0004 80453f47 804542d8 80429ff8 
 804a36c8 0341 80789384 01e0 803c70b0 8014a19c 80460ac8 80460acc
 804314ec  8042f408 80451dac 80789384 80173624 803c70b0 8014a19c
  0f00      
        
 ...
Call Trace:
[<8010abf0>] show_stack+0x50/0x84
[<8012100c>] __warn+0xe4/0x118
[<80121098>] warn_slowpath_null+0x1c/0x28
[<8014f7a0>] __irq_do_set_handler+0x144/0x1b4
[<8014f860>] __irq_set_handler+0x50/0x7c
[<80475f18>] rbtx4927_irq_setup+0xac/0xd0
[<8046e9

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Alban Browaeys]

Le vendredi 16 septembre 2016 à 13:55 +0100, Marc Zyngier a écrit :
> At that stage, I'm not sure I should care. Does the workaround make
> your
> platform usable?

However awkward this was all about logs and clearing worries. There was
no change in behavior  between the three cases : upstream, upstream
commit reverted and patched upstream.

Mind this hardware (the Odroid U2) has no hardware buttons. Only power
on plug.

Best regards,
Alban

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Alban Browaeys]

Le vendredi 16 septembre 2016 à 13:55 +0100, Marc Zyngier a écrit :
> At that stage, I'm not sure I should care. Does the workaround make
> your
> platform usable?

However awkward this was all about logs and clearing worries. There was
no change in behavior  between the three cases : upstream, upstream
commit reverted and patched upstream.

Mind this hardware (the Odroid U2) has no hardware buttons. Only power
on plug.

Best regards,
Alban

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Krzysztof Kozlowski]

On Fri, Sep 16, 2016 at 2:55 PM, Marc Zyngier  wrote:
> +Krzystof, Kukjin,
>
> On 16/09/16 12:03, Alban Browaeys wrote:
>> Le vendredi 16 septembre 2016 à 08:51 +0100, Marc Zyngier a écrit :
>>> Hi Alban,
>>>
>>> On 16/09/16 00:02, Alban Browaeys wrote:
 I am seeing this on arm odroid u2 devicetree :
 genirq: Setting trigger mode 0 for irq 16 failed
 (gic_set_type+0x0/0x64)
>>>
>>> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
>>> Can you point me to the various DTs and their failing interrupts?
>>
>> mine is:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidu3.dts
>>
>> I got a report of this issue to another odroid :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidx2.dts
>>
>>
>>
>> they both get their settings from :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412.dtsi
>>
>> relevant in the chain are:
>> - combiner modified:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12.dtsi#n460
>
> How wonderful. This section is an utter pile of crap. Really.
> Having 0 as the trigger is illegal, and the valid values are fully
> documented in the GIC binding. No wonder things start breaking.


+CC Marek Szyprowski,

Yes, that is interesting pile. Lately we stomped into it as well... I
started fixing this today but didn't finish it yet.

> And that's from the following stuff:
>
> _0 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x1140 0x1000>;
> interrupts = <0 47 0>;
> };
>
> _1 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x1100 0x1000>;
> interrupts = <0 46 0>;
>
> wakup_eint: wakeup-interrupt-controller {
> compatible = "samsung,exynos4210-wakeup-eint";
> interrupt-parent = <>;
> interrupts = <0 32 0>;
> };
> };
>
> [...]
>
> _3 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x106E 0x1000>;
> interrupts = <0 72 0>;
> };
>
> which perpetuates this fine tradition...
>
> At that stage, I'm not sure I should care. Does the workaround make your
> platform usable? The Samsung maintainers should really try and fix their
> DT, because it is a miracle this has made it that far.

Miracle or coincidence. :)

Thanks Geert and Alban for bringing this up, I'll add also yours reported-by.

Best regards,
Krzysztof

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Krzysztof Kozlowski]

On Fri, Sep 16, 2016 at 2:55 PM, Marc Zyngier  wrote:
> +Krzystof, Kukjin,
>
> On 16/09/16 12:03, Alban Browaeys wrote:
>> Le vendredi 16 septembre 2016 à 08:51 +0100, Marc Zyngier a écrit :
>>> Hi Alban,
>>>
>>> On 16/09/16 00:02, Alban Browaeys wrote:
 I am seeing this on arm odroid u2 devicetree :
 genirq: Setting trigger mode 0 for irq 16 failed
 (gic_set_type+0x0/0x64)
>>>
>>> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
>>> Can you point me to the various DTs and their failing interrupts?
>>
>> mine is:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidu3.dts
>>
>> I got a report of this issue to another odroid :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidx2.dts
>>
>>
>>
>> they both get their settings from :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412.dtsi
>>
>> relevant in the chain are:
>> - combiner modified:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12.dtsi#n460
>
> How wonderful. This section is an utter pile of crap. Really.
> Having 0 as the trigger is illegal, and the valid values are fully
> documented in the GIC binding. No wonder things start breaking.


+CC Marek Szyprowski,

Yes, that is interesting pile. Lately we stomped into it as well... I
started fixing this today but didn't finish it yet.

> And that's from the following stuff:
>
> _0 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x1140 0x1000>;
> interrupts = <0 47 0>;
> };
>
> _1 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x1100 0x1000>;
> interrupts = <0 46 0>;
>
> wakup_eint: wakeup-interrupt-controller {
> compatible = "samsung,exynos4210-wakeup-eint";
> interrupt-parent = <>;
> interrupts = <0 32 0>;
> };
> };
>
> [...]
>
> _3 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x106E 0x1000>;
> interrupts = <0 72 0>;
> };
>
> which perpetuates this fine tradition...
>
> At that stage, I'm not sure I should care. Does the workaround make your
> platform usable? The Samsung maintainers should really try and fix their
> DT, because it is a miracle this has made it that far.

Miracle or coincidence. :)

Thanks Geert and Alban for bringing this up, I'll add also yours reported-by.

Best regards,
Krzysztof

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Marc Zyngier]

+Krzystof, Kukjin,

On 16/09/16 12:03, Alban Browaeys wrote:
> Le vendredi 16 septembre 2016 à 08:51 +0100, Marc Zyngier a écrit :
>> Hi Alban,
>>
>> On 16/09/16 00:02, Alban Browaeys wrote:
>>> I am seeing this on arm odroid u2 devicetree :
>>> genirq: Setting trigger mode 0 for irq 16 failed
>>> (gic_set_type+0x0/0x64)
>>
>> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
>> Can you point me to the various DTs and their failing interrupts?
> 
> mine is:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidu3.dts
> 
> I got a report of this issue to another odroid :
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidx2.dts
> 
> 
> 
> they both get their settings from :
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412.dtsi
> 
> relevant in the chain are:
> - combiner modified:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12.dtsi#n460

How wonderful. This section is an utter pile of crap. Really.
Having 0 as the trigger is illegal, and the valid values are fully
documented in the GIC binding. No wonder things start breaking.

> - gic:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi#n576
> - gic and combiner initial settings:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4.dtsi#n134
> 
> 
> 
>> Also, can you please give the following patch a go and let me know
>> if that fixes the issue (I'm interested in the potential warning
>> here).
> 
> 1st batch of warnings is :
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 
> __irq_do_set_handler+0x1c0/0x1c4
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc6-debug+ #30
> Hardware name: ODROID-U2/U3
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xa8/0xd4)
> [] (dump_stack) from [] (__warn+0xe8/0x100)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] 
> (__irq_do_set_handler+0x1c0/0x1c4)
> [] (__irq_do_set_handler) from [] 
> (irq_set_chained_handler_and_data+0x38/0x54)
> [] (irq_set_chained_handler_and_data) from [] 
> (combiner_of_init+0x1a0/0x1c4)
> [] (combiner_of_init) from [] (of_irq_init+0x194/0x2e8)
> [] (of_irq_init) from [] (exynos_init_irq+0x8/0x3c)
> [] (exynos_init_irq) from [] (init_IRQ+0x2c/0x88)
> [] (init_IRQ) from [] (start_kernel+0x284/0x388)
> [] (start_kernel) from [<40008078>] (0x40008078)
> ---[ end trace f68728a0d3053b52 ]---

That's our above friend the combiner.

> 
> 2nd batch is :
> 
> [ cut here ]
> WARNING: CPU: 1 PID: 1 at kernel/irq/chip.c:833 
> __irq_do_set_handler+0x1c0/0x1c4
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   4.8.0-rc6-debug+ #30
> Hardware name: ODROID-U2/U3
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xa8/0xd4)
> [] (dump_stack) from [] (__warn+0xe8/0x100)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] 
> (__irq_do_set_handler+0x1c0/0x1c4)
> [] (__irq_do_set_handler) from [] 
> (irq_set_chained_handler_and_data+0x38/0x54)
> [] (irq_set_chained_handler_and_data) from [] 
> (exynos_eint_wkup_init+0x188/0x2dc)
> [] (exynos_eint_wkup_init) from [] 
> (samsung_pinctrl_probe+0x874/0xa18)
> [] (samsung_pinctrl_probe) from [] 
> (platform_drv_probe+0x4c/0xb0)
> [] (platform_drv_probe) from [] 
> (driver_probe_device+0x24c/0x440)
> [] (driver_probe_device) from [] 
> (bus_for_each_drv+0x64/0x98)
> [] (bus_for_each_drv) from [] (__device_attach+0xb4/0x144)
> [] (__device_attach) from [] (bus_probe_device+0x88/0x90)
> [] (bus_probe_device) from [] (device_add+0x428/0x5c8)
> [] (device_add) from [] 
> (of_platform_device_create_pdata+0x84/0xb8)
> [] (of_platform_device_create_pdata) from [] 
> (of_platform_bus_create+0x164/0x440)
> [] (of_platform_bus_create) from [] 
> (of_platform_populate+0x80/0x114)
> [] (of_platform_populate) from [] 
> (of_platform_default_populate_init+0x6c/0x80)
> [] (of_platform_default_populate_init) from [] 
> (do_one_initcall+0x50/0x198)
> [] (do_one_initcall) from [] 
> (kernel_init_freeable+0x250/0x2f0)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x24)
> ---[ end trace f68728a0d3053b66 ]---

And that's from the following stuff:

_0 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x1140 0x1000>;
interrupts = <0 47 0>;
};

_1 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x1100 0x1000>;
interrupts = <0 46 0>;

wakup_eint: wakeup-interrupt-controller {
 

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Marc Zyngier]

+Krzystof, Kukjin,

On 16/09/16 12:03, Alban Browaeys wrote:
> Le vendredi 16 septembre 2016 à 08:51 +0100, Marc Zyngier a écrit :
>> Hi Alban,
>>
>> On 16/09/16 00:02, Alban Browaeys wrote:
>>> I am seeing this on arm odroid u2 devicetree :
>>> genirq: Setting trigger mode 0 for irq 16 failed
>>> (gic_set_type+0x0/0x64)
>>
>> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
>> Can you point me to the various DTs and their failing interrupts?
> 
> mine is:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidu3.dts
> 
> I got a report of this issue to another odroid :
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidx2.dts
> 
> 
> 
> they both get their settings from :
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412.dtsi
> 
> relevant in the chain are:
> - combiner modified:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12.dtsi#n460

How wonderful. This section is an utter pile of crap. Really.
Having 0 as the trigger is illegal, and the valid values are fully
documented in the GIC binding. No wonder things start breaking.

> - gic:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi#n576
> - gic and combiner initial settings:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4.dtsi#n134
> 
> 
> 
>> Also, can you please give the following patch a go and let me know
>> if that fixes the issue (I'm interested in the potential warning
>> here).
> 
> 1st batch of warnings is :
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 
> __irq_do_set_handler+0x1c0/0x1c4
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc6-debug+ #30
> Hardware name: ODROID-U2/U3
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xa8/0xd4)
> [] (dump_stack) from [] (__warn+0xe8/0x100)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] 
> (__irq_do_set_handler+0x1c0/0x1c4)
> [] (__irq_do_set_handler) from [] 
> (irq_set_chained_handler_and_data+0x38/0x54)
> [] (irq_set_chained_handler_and_data) from [] 
> (combiner_of_init+0x1a0/0x1c4)
> [] (combiner_of_init) from [] (of_irq_init+0x194/0x2e8)
> [] (of_irq_init) from [] (exynos_init_irq+0x8/0x3c)
> [] (exynos_init_irq) from [] (init_IRQ+0x2c/0x88)
> [] (init_IRQ) from [] (start_kernel+0x284/0x388)
> [] (start_kernel) from [<40008078>] (0x40008078)
> ---[ end trace f68728a0d3053b52 ]---

That's our above friend the combiner.

> 
> 2nd batch is :
> 
> [ cut here ]
> WARNING: CPU: 1 PID: 1 at kernel/irq/chip.c:833 
> __irq_do_set_handler+0x1c0/0x1c4
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   4.8.0-rc6-debug+ #30
> Hardware name: ODROID-U2/U3
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xa8/0xd4)
> [] (dump_stack) from [] (__warn+0xe8/0x100)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] 
> (__irq_do_set_handler+0x1c0/0x1c4)
> [] (__irq_do_set_handler) from [] 
> (irq_set_chained_handler_and_data+0x38/0x54)
> [] (irq_set_chained_handler_and_data) from [] 
> (exynos_eint_wkup_init+0x188/0x2dc)
> [] (exynos_eint_wkup_init) from [] 
> (samsung_pinctrl_probe+0x874/0xa18)
> [] (samsung_pinctrl_probe) from [] 
> (platform_drv_probe+0x4c/0xb0)
> [] (platform_drv_probe) from [] 
> (driver_probe_device+0x24c/0x440)
> [] (driver_probe_device) from [] 
> (bus_for_each_drv+0x64/0x98)
> [] (bus_for_each_drv) from [] (__device_attach+0xb4/0x144)
> [] (__device_attach) from [] (bus_probe_device+0x88/0x90)
> [] (bus_probe_device) from [] (device_add+0x428/0x5c8)
> [] (device_add) from [] 
> (of_platform_device_create_pdata+0x84/0xb8)
> [] (of_platform_device_create_pdata) from [] 
> (of_platform_bus_create+0x164/0x440)
> [] (of_platform_bus_create) from [] 
> (of_platform_populate+0x80/0x114)
> [] (of_platform_populate) from [] 
> (of_platform_default_populate_init+0x6c/0x80)
> [] (of_platform_default_populate_init) from [] 
> (do_one_initcall+0x50/0x198)
> [] (do_one_initcall) from [] 
> (kernel_init_freeable+0x250/0x2f0)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x24)
> ---[ end trace f68728a0d3053b66 ]---

And that's from the following stuff:

_0 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x1140 0x1000>;
interrupts = <0 47 0>;
};

_1 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x1100 0x1000>;
interrupts = <0 46 0>;

wakup_eint: wakeup-interrupt-controller {
 

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Alban Browaeys]

Le vendredi 16 septembre 2016 à 08:51 +0100, Marc Zyngier a écrit :
> Hi Alban,
> 
> On 16/09/16 00:02, Alban Browaeys wrote:
> > I am seeing this on arm odroid u2 devicetree :
> > genirq: Setting trigger mode 0 for irq 16 failed
> > (gic_set_type+0x0/0x64)
> 
> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
> Can you point me to the various DTs and their failing interrupts?

mine is:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidu3.dts

I got a report of this issue to another odroid :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidx2.dts



they both get their settings from :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412.dtsi

relevant in the chain are:
- combiner modified:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12.dtsi#n460
- gic:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi#n576
- gic and combiner initial settings:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4.dtsi#n134



> Also, can you please give the following patch a go and let me know
> if that fixes the issue (I'm interested in the potential warning
> here).

1st batch of warnings is :

[ cut here ]
WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 __irq_do_set_handler+0x1c0/0x1c4
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc6-debug+ #30
Hardware name: ODROID-U2/U3
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xa8/0xd4)
[] (dump_stack) from [] (__warn+0xe8/0x100)
[] (__warn) from [] (warn_slowpath_null+0x20/0x28)
[] (warn_slowpath_null) from [] 
(__irq_do_set_handler+0x1c0/0x1c4)
[] (__irq_do_set_handler) from [] 
(irq_set_chained_handler_and_data+0x38/0x54)
[] (irq_set_chained_handler_and_data) from [] 
(combiner_of_init+0x1a0/0x1c4)
[] (combiner_of_init) from [] (of_irq_init+0x194/0x2e8)
[] (of_irq_init) from [] (exynos_init_irq+0x8/0x3c)
[] (exynos_init_irq) from [] (init_IRQ+0x2c/0x88)
[] (init_IRQ) from [] (start_kernel+0x284/0x388)
[] (start_kernel) from [<40008078>] (0x40008078)
---[ end trace f68728a0d3053b52 ]---

2nd batch is :

[ cut here ]
WARNING: CPU: 1 PID: 1 at kernel/irq/chip.c:833 __irq_do_set_handler+0x1c0/0x1c4
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   4.8.0-rc6-debug+ #30
Hardware name: ODROID-U2/U3
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xa8/0xd4)
[] (dump_stack) from [] (__warn+0xe8/0x100)
[] (__warn) from [] (warn_slowpath_null+0x20/0x28)
[] (warn_slowpath_null) from [] 
(__irq_do_set_handler+0x1c0/0x1c4)
[] (__irq_do_set_handler) from [] 
(irq_set_chained_handler_and_data+0x38/0x54)
[] (irq_set_chained_handler_and_data) from [] 
(exynos_eint_wkup_init+0x188/0x2dc)
[] (exynos_eint_wkup_init) from [] 
(samsung_pinctrl_probe+0x874/0xa18)
[] (samsung_pinctrl_probe) from [] 
(platform_drv_probe+0x4c/0xb0)
[] (platform_drv_probe) from [] 
(driver_probe_device+0x24c/0x440)
[] (driver_probe_device) from [] 
(bus_for_each_drv+0x64/0x98)
[] (bus_for_each_drv) from [] (__device_attach+0xb4/0x144)
[] (__device_attach) from [] (bus_probe_device+0x88/0x90)
[] (bus_probe_device) from [] (device_add+0x428/0x5c8)
[] (device_add) from [] 
(of_platform_device_create_pdata+0x84/0xb8)
[] (of_platform_device_create_pdata) from [] 
(of_platform_bus_create+0x164/0x440)
[] (of_platform_bus_create) from [] 
(of_platform_populate+0x80/0x114)
[] (of_platform_populate) from [] 
(of_platform_default_populate_init+0x6c/0x80)
[] (of_platform_default_populate_init) from [] 
(do_one_initcall+0x50/0x198)
[] (do_one_initcall) from [] 
(kernel_init_freeable+0x250/0x2f0)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
[] (kernel_init) from [] (ret_from_fork+0x14/0x24)
---[ end trace f68728a0d3053b66 ]---



Best regards,
Alban

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Alban Browaeys]

Le vendredi 16 septembre 2016 à 08:51 +0100, Marc Zyngier a écrit :
> Hi Alban,
> 
> On 16/09/16 00:02, Alban Browaeys wrote:
> > I am seeing this on arm odroid u2 devicetree :
> > genirq: Setting trigger mode 0 for irq 16 failed
> > (gic_set_type+0x0/0x64)
> 
> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
> Can you point me to the various DTs and their failing interrupts?

mine is:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidu3.dts

I got a report of this issue to another odroid :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidx2.dts



they both get their settings from :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412.dtsi

relevant in the chain are:
- combiner modified:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12.dtsi#n460
- gic:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi#n576
- gic and combiner initial settings:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4.dtsi#n134



> Also, can you please give the following patch a go and let me know
> if that fixes the issue (I'm interested in the potential warning
> here).

1st batch of warnings is :

[ cut here ]
WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 __irq_do_set_handler+0x1c0/0x1c4
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc6-debug+ #30
Hardware name: ODROID-U2/U3
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xa8/0xd4)
[] (dump_stack) from [] (__warn+0xe8/0x100)
[] (__warn) from [] (warn_slowpath_null+0x20/0x28)
[] (warn_slowpath_null) from [] 
(__irq_do_set_handler+0x1c0/0x1c4)
[] (__irq_do_set_handler) from [] 
(irq_set_chained_handler_and_data+0x38/0x54)
[] (irq_set_chained_handler_and_data) from [] 
(combiner_of_init+0x1a0/0x1c4)
[] (combiner_of_init) from [] (of_irq_init+0x194/0x2e8)
[] (of_irq_init) from [] (exynos_init_irq+0x8/0x3c)
[] (exynos_init_irq) from [] (init_IRQ+0x2c/0x88)
[] (init_IRQ) from [] (start_kernel+0x284/0x388)
[] (start_kernel) from [<40008078>] (0x40008078)
---[ end trace f68728a0d3053b52 ]---

2nd batch is :

[ cut here ]
WARNING: CPU: 1 PID: 1 at kernel/irq/chip.c:833 __irq_do_set_handler+0x1c0/0x1c4
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   4.8.0-rc6-debug+ #30
Hardware name: ODROID-U2/U3
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xa8/0xd4)
[] (dump_stack) from [] (__warn+0xe8/0x100)
[] (__warn) from [] (warn_slowpath_null+0x20/0x28)
[] (warn_slowpath_null) from [] 
(__irq_do_set_handler+0x1c0/0x1c4)
[] (__irq_do_set_handler) from [] 
(irq_set_chained_handler_and_data+0x38/0x54)
[] (irq_set_chained_handler_and_data) from [] 
(exynos_eint_wkup_init+0x188/0x2dc)
[] (exynos_eint_wkup_init) from [] 
(samsung_pinctrl_probe+0x874/0xa18)
[] (samsung_pinctrl_probe) from [] 
(platform_drv_probe+0x4c/0xb0)
[] (platform_drv_probe) from [] 
(driver_probe_device+0x24c/0x440)
[] (driver_probe_device) from [] 
(bus_for_each_drv+0x64/0x98)
[] (bus_for_each_drv) from [] (__device_attach+0xb4/0x144)
[] (__device_attach) from [] (bus_probe_device+0x88/0x90)
[] (bus_probe_device) from [] (device_add+0x428/0x5c8)
[] (device_add) from [] 
(of_platform_device_create_pdata+0x84/0xb8)
[] (of_platform_device_create_pdata) from [] 
(of_platform_bus_create+0x164/0x440)
[] (of_platform_bus_create) from [] 
(of_platform_populate+0x80/0x114)
[] (of_platform_populate) from [] 
(of_platform_default_populate_init+0x6c/0x80)
[] (of_platform_default_populate_init) from [] 
(do_one_initcall+0x50/0x198)
[] (do_one_initcall) from [] 
(kernel_init_freeable+0x250/0x2f0)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
[] (kernel_init) from [] (ret_from_fork+0x14/0x24)
---[ end trace f68728a0d3053b66 ]---



Best regards,
Alban

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Marc Zyngier]

Hi Alban,

On 16/09/16 00:02, Alban Browaeys wrote:
> Le mercredi 14 septembre 2016 à 21:25 +0200, Geert Uytterhoeven a
> écrit :
>> JFYI, with v4.8-rc6 I'm seeing
>>
>> genirq: Setting trigger mode 0 for irq 11 failed
>> (txx9_irq_set_type+0x0/0xb8)
>>
>> on rbtx4927. This did not happen with v4.8-rc3.
> 
> 
> txx9_irq_set_type receives a type IRQ_TYPE_NONE from the call to
> __irq_set_trigger added in:
> 1e12c4a939 ("genirq: Correctly configure the trigger on chained interrupts")
> 
> 
> This patch is a regression fix for :
> 
> Desc: irqdomain: Don't set type when mapping an IRQ breaks nexus7 gpio buttons
> Repo: 2016-07-30 https://marc.info/?l=linux-kernel=146985356305280=2
> 
> I am seeing this on arm odroid u2 devicetree :
> genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x64)

Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
Can you point me to the various DTs and their failing interrupts?

Also, can you please give the following patch a go and let me know
if that fixes the issue (I'm interested in the potential warning here).

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6373890..8422779 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -820,6 +820,8 @@ __irq_do_set_handler(struct irq_desc *desc, 
irq_flow_handler_t handle,
desc->name = name;
 
if (handle != handle_bad_irq && is_chained) {
+   unsigned int type = irqd_get_trigger_type(>irq_data);
+
/*
 * We're about to start this interrupt immediately,
 * hence the need to set the trigger configuration.
@@ -828,8 +830,10 @@ __irq_do_set_handler(struct irq_desc *desc, 
irq_flow_handler_t handle,
 * chained interrupt. Reset it immediately because we
 * do know better.
 */
-   __irq_set_trigger(desc, irqd_get_trigger_type(>irq_data));
-   desc->handle_irq = handle;
+   if (!(WARN_ON(type == IRQ_TYPE_NONE))) {
+   __irq_set_trigger(desc, type);
+   desc->handle_irq = handle;
+   }
 
irq_settings_set_noprobe(desc);
irq_settings_set_norequest(desc);

Thanks,

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

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Marc Zyngier]

Hi Alban,

On 16/09/16 00:02, Alban Browaeys wrote:
> Le mercredi 14 septembre 2016 à 21:25 +0200, Geert Uytterhoeven a
> écrit :
>> JFYI, with v4.8-rc6 I'm seeing
>>
>> genirq: Setting trigger mode 0 for irq 11 failed
>> (txx9_irq_set_type+0x0/0xb8)
>>
>> on rbtx4927. This did not happen with v4.8-rc3.
> 
> 
> txx9_irq_set_type receives a type IRQ_TYPE_NONE from the call to
> __irq_set_trigger added in:
> 1e12c4a939 ("genirq: Correctly configure the trigger on chained interrupts")
> 
> 
> This patch is a regression fix for :
> 
> Desc: irqdomain: Don't set type when mapping an IRQ breaks nexus7 gpio buttons
> Repo: 2016-07-30 https://marc.info/?l=linux-kernel=146985356305280=2
> 
> I am seeing this on arm odroid u2 devicetree :
> genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x64)

Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
Can you point me to the various DTs and their failing interrupts?

Also, can you please give the following patch a go and let me know
if that fixes the issue (I'm interested in the potential warning here).

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6373890..8422779 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -820,6 +820,8 @@ __irq_do_set_handler(struct irq_desc *desc, 
irq_flow_handler_t handle,
desc->name = name;
 
if (handle != handle_bad_irq && is_chained) {
+   unsigned int type = irqd_get_trigger_type(>irq_data);
+
/*
 * We're about to start this interrupt immediately,
 * hence the need to set the trigger configuration.
@@ -828,8 +830,10 @@ __irq_do_set_handler(struct irq_desc *desc, 
irq_flow_handler_t handle,
 * chained interrupt. Reset it immediately because we
 * do know better.
 */
-   __irq_set_trigger(desc, irqd_get_trigger_type(>irq_data));
-   desc->handle_irq = handle;
+   if (!(WARN_ON(type == IRQ_TYPE_NONE))) {
+   __irq_set_trigger(desc, type);
+   desc->handle_irq = handle;
+   }
 
irq_settings_set_noprobe(desc);
irq_settings_set_norequest(desc);

Thanks,

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

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Alban Browaeys]

Le mercredi 14 septembre 2016 à 21:25 +0200, Geert Uytterhoeven a
écrit :
> JFYI, with v4.8-rc6 I'm seeing
> 
>     genirq: Setting trigger mode 0 for irq 11 failed
> (txx9_irq_set_type+0x0/0xb8)
> 
> on rbtx4927. This did not happen with v4.8-rc3.


txx9_irq_set_type receives a type IRQ_TYPE_NONE from the call to
__irq_set_trigger added in:
1e12c4a939 ("genirq: Correctly configure the trigger on chained interrupts")


This patch is a regression fix for :

Desc: irqdomain: Don't set type when mapping an IRQ breaks nexus7 gpio buttons
Repo: 2016-07-30 https://marc.info/?l=linux-kernel=146985356305280=2

I am seeing this on arm odroid u2 devicetree :
genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x64)


Alban

Re: genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Alban Browaeys]

Le mercredi 14 septembre 2016 à 21:25 +0200, Geert Uytterhoeven a
écrit :
> JFYI, with v4.8-rc6 I'm seeing
> 
>     genirq: Setting trigger mode 0 for irq 11 failed
> (txx9_irq_set_type+0x0/0xb8)
> 
> on rbtx4927. This did not happen with v4.8-rc3.


txx9_irq_set_type receives a type IRQ_TYPE_NONE from the call to
__irq_set_trigger added in:
1e12c4a939 ("genirq: Correctly configure the trigger on chained interrupts")


This patch is a regression fix for :

Desc: irqdomain: Don't set type when mapping an IRQ breaks nexus7 gpio buttons
Repo: 2016-07-30 https://marc.info/?l=linux-kernel=146985356305280=2

I am seeing this on arm odroid u2 devicetree :
genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x64)


Alban

genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Geert Uytterhoeven]

Hi Nemoto-san,

JFYI, with v4.8-rc6 I'm seeing

genirq: Setting trigger mode 0 for irq 11 failed
(txx9_irq_set_type+0x0/0xb8)

on rbtx4927. This did not happen with v4.8-rc3.

No idea yet if this has any ill effects...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)

[Geert Uytterhoeven]

Hi Nemoto-san,

JFYI, with v4.8-rc6 I'm seeing

genirq: Setting trigger mode 0 for irq 11 failed
(txx9_irq_set_type+0x0/0xb8)

on rbtx4927. This did not happen with v4.8-rc3.

No idea yet if this has any ill effects...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds