Re: [PATCH] iio: accel: bmc150: free irq before teardown

[Melbin K Mathew <mlbnkm1@gmail.com>]

Thanks for the review.

I double checked the remove path.  The remaining hardware accesses after
freeing the IRQ are synchronous regmap accesses and do not rely on the 
IRQ being enabled.

In particular, iio_device_unregister() may disable the buffer path, 
which can call into the buffer predisable path and synchronously disable 
the FIFO interrupt, flush the FIFO and update the FIFO mode.  Later 
remove explicitly puts the device into deep suspend via 
bmc150_accel_set_mode().  These paths do not wait for an interrupt or 
use the threaded IRQ handler for completion.

The IRQ handler itself is only used for asynchronous trigger polling,
FIFO/event handling and interrupt latch acknowledgement, so freeing it 
before the rest of teardown should not remove anything that the remove 
path depends on.

On 05/07/2026 07:53, Andy Shevchenko wrote:
> On Sun, Jul 05, 2026 at 06:27:31AM +0200, Melbin K Mathew wrote:
>> bmc150_accel_core_probe() requests the interrupt with
>> devm_request_threaded_irq().  The managed IRQ is released only after the
>> driver remove callback has returned unless it is freed explicitly.
>>
>> bmc150_accel_core_remove() currently unregisters the IIO device and
>> triggers, cleans up the triggered buffer, suspends the chip and disables
>> the regulators while the IRQ action is still registered.  A late
>> interrupt can therefore run the hard or threaded handler while the IIO
>> trigger state is being torn down or after the device has been put into
>> deep suspend.
>>
>> Free the IRQ at the start of remove so that no handler is running while
>> the rest of the driver state and hardware resources are dismantled.
> 
> In general this is correct fix, but have you checked the rest of remove if it
> has any communication with HW and if that communication relies on IRQ to be on?
> 
> (*yes, this is very unlikely, but please double check as rarely we have some HW
>   that might need that, and in such a case the fix might be different)
> 
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>