spi->irq == 0 on module reload of driver using IRQF_TRIGGER_LOW

Marc Zyngier
2017-11-12T14:13:49Z

On Sun, 12 Nov 2017 13:32:44 +0100
<kernel@martin.sperl.org> wrote:

Martin,

> Hi!
>
> During the development of a new spi driver on a raspberry pi CM1
> I have seen an issue with the following code triggering strange behavior:
>
> ret = request_threaded_irq(spi->irq, NULL,
> mcp2517fd_can_ist,
> IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> DEVICE_NAME, priv);
>
> This works fine the first time the module is loaded (spi->irq is not 0),
> but as soon as the module gets removed and reinstalled spi->irq is 0
> and I get the message in dmesg:
> [ 1282.311991] irq: type mismatch, failed to map hwirq-16 for /soc/gpio at 7e200000!
>
> This does not happen when using the IRQF_TRIGGER_FALLING flag.
>
> in spi_drv_probe spi core does sets spi->dev to 0 in case
> of_irq_get returns < 0;
>
> The specific code that triggers this message and return 0 is
> irq_create_fwspec_mapping.
>
> After implementing: https://www.spinics.net/lists/arm-kernel/msg528469.html
> and also checking for spi->irq == 0, I get:
>
> [ 87.867456] irq: type mismatch (2/8), failed to map hwirq-16 for /soc/gpio at 7e200000!

Well, you have the answer here: The interrupt has been configured with
a falling edge trigger, while you're requesting a level low. Obviously,
something is changing it.

It would be interesting to see both the driver code and the DT file
where the interrupt is described...

> [ 87.867512] mcp2517fd spi0.0: no valid irq line defined: irq = 0
>
> The test for irq == 0 is the first thing that happens in the
> spi.driver.probe code of the module.
>
> So to me it looks as if something deeper down the stack during
> initialization.
>
> As if the irq-type is not cleaned up during release of the irq on module
> unload - which I can confirm calls free_irq(spi->irq, priv).

I don't really understand this remark. The trigger type is a property
of the generating device, so "cleaning up" doesn't make much sense
(even if you;re not using the interrupt anymore, the device is still
there).

Thanks,

M.
--
Without deviation from the norm, progress is not possible.