Using IRQF_TRIGGER_LOW results in spi->irq = 0 after module reload

[msperl]

Hi!

Strange observation while writing a new driver:

When using the flags: IRQF_ONESHOT | IRQF_TRIGGER_LOW with request_threaded_irq I see that after I unload and reload the module that the spi->irq value is 0.

When instrumenting my code dumping spi->irq in the remove and probe code, then I get the following messages in demsg:

[ 1282.222746] mcp2517fd spi0.0: remove: IRQ: 176
[ 1282.311991] irq: type mismatch, failed to map hwirq-16 for /soc/gpio@7e200000!
[ 1282.312031] mcp2517fd spi0.0: probe: IRQ: 0

Only solution is rebooting the rpi - then it works

This does not happen when using IRQF_ONESHOT | IRQF_TRIGGER_FALLING. I can go thru the rmmod, insmod sequence 100 times without requiring a reboot.

Any Ideas why this could be and how to solve it?

Not using TRIGGER_LOW gives me a race-condition in my interrupt handler...

Any ideas?

Thanks, Martin

P.s: I am using is: 4.9.57 - commit: 2dddb0415295. I have not tried using the upstream kernel yet... Sidenote: I use the default devicetree for the CM1 (bcm2708-rpi-cm.dtb) with a simple dt-overlay based on mcp2515-can0.

[msperl]

Note that after applying this (debugging) patch: https://www.spinics.net/lists/arm-kernel/msg528469.html

I get:

[   64.049763] mcp2517fd spi0.0: remove: IRQ: 176
[   64.165360] irq: type mismatch (2/8), failed to map hwirq-16 for /soc/gpio@7e200000!
[   64.165404] mcp2517fd spi0.0: probe: IRQ: 0
[   64.201945] mcp2517fd spi0.0: probe2: IRQ: 0

type 2 = IRQ_TYPE_EDGE_FALLING type 8 = IRQ_TYPE_LEVEL_LOW

So I wonder how this type gets set to IRQ_TYPE_EDGE_FALLING.

[msperl]

For completeness here the request_irq portion of the code:

    ret = request_threaded_irq(spi->irq, NULL,
                   mcp2517fd_can_ist,
                   IRQF_ONESHOT | IRQF_TRIGGER_LOW,
//                 IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
                   DEVICE_NAME, priv);

You also can see the FALLING_LOW that does not show this behaviour...

[msperl]

I have tried with the upstream 4.14.0-rc4 as well and the same issue shows there as well...

[msperl]

Turns out that this needs to get set in the device tree as well to work correctly...

[pelwell]

See https://github.com/raspberrypi/linux/pull/2267.