On Mon, 15 Jun 2020 at 17:57, Krzysztof Kozlowski krzk@kernel.org wrote:
On Mon, Jun 15, 2020 at 05:23:28PM +0300, Vladimir Oltean wrote:
On Mon, 15 Jun 2020 at 16:41, Krzysztof Kozlowski krzk@kernel.org wrote:
On Mon, Jun 15, 2020 at 04:12:28PM +0300, Vladimir Oltean wrote:
On Mon, 15 Jun 2020 at 16:10, Mark Brown broonie@kernel.org wrote:
It's a bit unusual to need to actually free the IRQ over suspend - what's driving that requirement here?
clk_disable_unprepare(dspi->clk); is driving the requirement - same as in dspi_remove case, the module will fault when its registers are accessed without a clock.
In few cases when I have shared interrupt in different drivers, they were just disabling it during suspend. Why it has to be freed?
Best regards, Krzysztof
Not saying it _has_ to be freed, just to be prevented from running concurrently with us disabling the clock. But if we can get away in dspi_suspend with just disable_irq, can't we also get away in dspi_remove with just devm_free_irq?
One reason why they have to be different could be following scenario:
- Device could be unbound any time and disabling IRQ in remove() would effectively disable the IRQ also for other devices using this shared line. First disable_irq() really disables it, the latter just increases the counter.
- However during system suspend, it is expected that all drivers in their suspend (and later resume) callbacks will do the same - disable the shared IRQ line. And finally the system disables interrupts globally so the line will be balanced.
Freeing IRQ solves the case #1 without causing any imbalance between enables/disables or requests/frees. Disabling IRQ solves the #2, also without any imbalance.
Best regards, Krzysztof
So the answer to my question is 'yes', right?