On Mon, 15 Jun 2020 at 17:57, Krzysztof Kozlowski <krzk@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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: > 1. 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. > 2. 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?