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

[marc.zyngier@arm.com (Marc Zyngier)]

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.