On 01/08/2023 00:50, Michał Mirosław wrote: > On Mon, Jul 31, 2023 at 02:59:41PM +0200, Krzysztof Kozlowski wrote: >> On 31/07/2023 10:49, Michał Mirosław wrote: >>> On Mon, Jul 31, 2023 at 08:58:14AM +0200, Krzysztof Kozlowski wrote: >>>> On 30/07/2023 23:55, Michał Mirosław wrote: >>>>> On Sun, Jul 30, 2023 at 10:30:56PM +0200, Krzysztof Kozlowski wrote: >>>>>> On 29/07/2023 18:08, Svyatoslav Ryhel wrote: >>>>>>> From: Michał Mirosław <mirq-linux@xxxxxxxxxxxx> >>>>>>> >>>>>>> Implement driver for hot-plugged I2C busses, where some devices on >>>>>>> a bus are hot-pluggable and their presence is indicated by GPIO line. >>>>> [...] >>>>>>> + priv->irq = platform_get_irq(pdev, 0); >>>>>>> + if (priv->irq < 0) >>>>>>> + return dev_err_probe(&pdev->dev, priv->irq, >>>>>>> + "failed to get IRQ %d\n", priv->irq); >>>>>>> + >>>>>>> + ret = devm_request_threaded_irq(&pdev->dev, priv->irq, NULL, >>>>>>> + i2c_hotplug_interrupt, >>>>>>> + IRQF_ONESHOT | IRQF_SHARED, >>>>>> >>>>>> Shared IRQ with devm is a recipe for disaster. Are you sure this is a >>>>>> shared one? You have a remove() function which also points that it is >>>>>> not safe. You can: >>>>>> 1. investigate to be sure it is 100% safe (please document why do you >>>>>> think it is safe) >>>>> >>>>> Could you elaborate on what is unsafe in using devm with shared >>>>> interrupts (as compared to non-shared or not devm-managed)? >>>>> >>>>> The remove function is indeed reversing the order of cleanup. The >>>>> shutdown path can be fixed by removing `remove()` and adding >>>>> `devm_add_action_or_reset(...deactivate)` before the IRQ is registered. >>>> Shared interrupt might be triggered easily by other device between >>>> remove() and irq release function (devm_free_irq() or whatever it is >>>> called). >>> >>> This is no different tham a non-shared interrupt that can be triggered >>> by the device being removed. Since devres will release the IRQ first, >>> before freeing the driver data, the interrupt hander will see consistent >>> driver-internal state. (The difference between remove() and devres >>> release phase is that for the latter sysfs files are already removed.) >> >> True, therefore non-devm interrupts are recommended also in such case. >> Maybe one of my solutions is actually not recommended. >> >> However if done right, driver with non-shared interrupts, is expected to >> disable interrupts in remove(), thus there is no risk. We have big >> discussions in the past about it, so feel free to dig through LKML to >> read more about. Anyway shared and devm is a clear no go. > > Can you share pointers to some of those discussions? Quick search > about devm_request_irq() and friends found only a thread from 2013 Just look at CONFIG_DEBUG_SHIRQ. Some things lore points: https://lore.kernel.org/all/1592130544-19759-2-git-send-email-krzk@xxxxxxxxxx/ https://lore.kernel.org/all/20200616103956.GL4447@xxxxxxxxxxxxx/ I think pretty clear: https://lore.kernel.org/all/87mu52ca4b.fsf@xxxxxxxxxxxxxxxxxxxxxxx/ https://lore.kernel.org/all/CA+h21hrxQ1fRahyQGFS42Xuop_Q2petE=No1dft4nVb-ijUu2g@xxxxxxxxxxxxxx/ Also: https://lore.kernel.org/all/651c9a33-71e6-c042-58e2-6ad501e984cd@xxxxxxxxxxxxxx/ https://lore.kernel.org/all/36AC4067-78C6-4986-8B97-591F93E266D8@xxxxxxxxx/ > about conversions of RTC drivers to use devres. [1] IIRC the issue was > then that the drivers requested IRQs before fully initializing the state > (as many still do). Back to the original question: what is the risk > in using devres with shared interrupts? (Let's assume the probe() is already > fixed and remove() removed.) > > BTW, We have devres doc [2] in the kernel tree that, among other things, > lists IRQs as a managed resource and mentions no warnings nor restictions > for driver authors. I'd expect that if devm_request_threaded_irq() for > shared iterrupts was indeed deprecated, it should be documented in a way > easy to refer to. > > [1] https://groups.google.com/g/linux.kernel/c/yi2ueo-sNJs > [2] Documentation/udriver-api/driver-model/devres.rst That's not really an argument. For some reason we have CONFIG_DEBUG_SHIRQ, right? If you think documentation is missing, everyone is encouraged to fix it, but lack of documentation is not a proof of some correct code pattern. Best regards, Krzysztof