* genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)
[not found] ` <1474023805.17258.10.camel@gmail.com>
@ 2016-09-16 12:55 ` Marc Zyngier
2016-09-16 13:16 ` Krzysztof Kozlowski
2016-09-16 13:35 ` Alban Browaeys
0 siblings, 2 replies; 3+ messages in thread
From: Marc Zyngier @ 2016-09-16 12:55 UTC (permalink / raw)
To: linux-arm-kernel
+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
> [<c010fc74>] (unwind_backtrace) from [<c010c9a0>] (show_stack+0x10/0x14)
> [<c010c9a0>] (show_stack) from [<c035cafc>] (dump_stack+0xa8/0xd4)
> [<c035cafc>] (dump_stack) from [<c01214dc>] (__warn+0xe8/0x100)
> [<c01214dc>] (__warn) from [<c01215a4>] (warn_slowpath_null+0x20/0x28)
> [<c01215a4>] (warn_slowpath_null) from [<c017d394>] (__irq_do_set_handler+0x1c0/0x1c4)
> [<c017d394>] (__irq_do_set_handler) from [<c017d450>] (irq_set_chained_handler_and_data+0x38/0x54)
> [<c017d450>] (irq_set_chained_handler_and_data) from [<c0a15878>] (combiner_of_init+0x1a0/0x1c4)
> [<c0a15878>] (combiner_of_init) from [<c0a1ead4>] (of_irq_init+0x194/0x2e8)
> [<c0a1ead4>] (of_irq_init) from [<c0a07450>] (exynos_init_irq+0x8/0x3c)
> [<c0a07450>] (exynos_init_irq) from [<c0a0190c>] (init_IRQ+0x2c/0x88)
> [<c0a0190c>] (init_IRQ) from [<c0a00b78>] (start_kernel+0x284/0x388)
> [<c0a00b78>] (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: G W 4.8.0-rc6-debug+ #30
> Hardware name: ODROID-U2/U3
> [<c010fc74>] (unwind_backtrace) from [<c010c9a0>] (show_stack+0x10/0x14)
> [<c010c9a0>] (show_stack) from [<c035cafc>] (dump_stack+0xa8/0xd4)
> [<c035cafc>] (dump_stack) from [<c01214dc>] (__warn+0xe8/0x100)
> [<c01214dc>] (__warn) from [<c01215a4>] (warn_slowpath_null+0x20/0x28)
> [<c01215a4>] (warn_slowpath_null) from [<c017d394>] (__irq_do_set_handler+0x1c0/0x1c4)
> [<c017d394>] (__irq_do_set_handler) from [<c017d450>] (irq_set_chained_handler_and_data+0x38/0x54)
> [<c017d450>] (irq_set_chained_handler_and_data) from [<c038e340>] (exynos_eint_wkup_init+0x188/0x2dc)
> [<c038e340>] (exynos_eint_wkup_init) from [<c038d668>] (samsung_pinctrl_probe+0x874/0xa18)
> [<c038d668>] (samsung_pinctrl_probe) from [<c04342c8>] (platform_drv_probe+0x4c/0xb0)
> [<c04342c8>] (platform_drv_probe) from [<c043267c>] (driver_probe_device+0x24c/0x440)
> [<c043267c>] (driver_probe_device) from [<c0430658>] (bus_for_each_drv+0x64/0x98)
> [<c0430658>] (bus_for_each_drv) from [<c04322e8>] (__device_attach+0xb4/0x144)
> [<c04322e8>] (__device_attach) from [<c04316f4>] (bus_probe_device+0x88/0x90)
> [<c04316f4>] (bus_probe_device) from [<c042f850>] (device_add+0x428/0x5c8)
> [<c042f850>] (device_add) from [<c054c3f8>] (of_platform_device_create_pdata+0x84/0xb8)
> [<c054c3f8>] (of_platform_device_create_pdata) from [<c054c59c>] (of_platform_bus_create+0x164/0x440)
> [<c054c59c>] (of_platform_bus_create) from [<c054ca20>] (of_platform_populate+0x80/0x114)
> [<c054ca20>] (of_platform_populate) from [<c0a1d458>] (of_platform_default_populate_init+0x6c/0x80)
> [<c0a1d458>] (of_platform_default_populate_init) from [<c01018d4>] (do_one_initcall+0x50/0x198)
> [<c01018d4>] (do_one_initcall) from [<c0a00ecc>] (kernel_init_freeable+0x250/0x2f0)
> [<c0a00ecc>] (kernel_init_freeable) from [<c06c1064>] (kernel_init+0x8/0x114)
> [<c06c1064>] (kernel_init) from [<c0108710>] (ret_from_fork+0x14/0x24)
> ---[ end trace f68728a0d3053b66 ]---
And that's from the following stuff:
&pinctrl_0 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x11400000 0x1000>;
interrupts = <0 47 0>;
};
&pinctrl_1 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x11000000 0x1000>;
interrupts = <0 46 0>;
wakup_eint: wakeup-interrupt-controller {
compatible = "samsung,exynos4210-wakeup-eint";
interrupt-parent = <&gic>;
interrupts = <0 32 0>;
};
};
[...]
&pinctrl_3 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x106E0000 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.
I'm also interested in hearing from Geert, whose platform doesn't seem
to be DT driven.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 3+ messages in thread
* genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)
2016-09-16 12:55 ` genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8) Marc Zyngier
@ 2016-09-16 13:16 ` Krzysztof Kozlowski
2016-09-16 13:35 ` Alban Browaeys
1 sibling, 0 replies; 3+ messages in thread
From: Krzysztof Kozlowski @ 2016-09-16 13:16 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 16, 2016 at 2:55 PM, Marc Zyngier <marc.zyngier@arm.com> 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:
>
> &pinctrl_0 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x11400000 0x1000>;
> interrupts = <0 47 0>;
> };
>
> &pinctrl_1 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x11000000 0x1000>;
> interrupts = <0 46 0>;
>
> wakup_eint: wakeup-interrupt-controller {
> compatible = "samsung,exynos4210-wakeup-eint";
> interrupt-parent = <&gic>;
> interrupts = <0 32 0>;
> };
> };
>
> [...]
>
> &pinctrl_3 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x106E0000 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)
2016-09-16 12:55 ` genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8) Marc Zyngier
2016-09-16 13:16 ` Krzysztof Kozlowski
@ 2016-09-16 13:35 ` Alban Browaeys
1 sibling, 0 replies; 3+ messages in thread
From: Alban Browaeys @ 2016-09-16 13:35 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-09-16 13:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAMuHMdVW1eTn20=EtYcJ8hkVwohaSuH_yQXrY2MGBEvZ8fpFOg@mail.gmail.com>
[not found] ` <1473980577.17787.21.camel@gmail.com>
[not found] ` <57DBA464.9010506@arm.com>
[not found] ` <1474023805.17258.10.camel@gmail.com>
2016-09-16 12:55 ` genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8) Marc Zyngier
2016-09-16 13:16 ` Krzysztof Kozlowski
2016-09-16 13:35 ` Alban Browaeys
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).