On Wed, Jul 6, 2016 at 6:37 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote:
> On the other hand
>
> static int probe(...)
> {
> ...
> dev_state_struct = devm_kzalloc();
> ...
> request_irq(...);
> ...
> return 0;
> }
>
>
>
> static int remove(...)
> {
> ...
> free_irq(...);
> return 0;
> }
>
> is safe to switch to devm_request_irq() since it will not change the
> ordering since free_irq() is already the last instruction executed in the
> remove function. devm will make sure that deallocation happens in the
> opposite order of allocation.
I think that the common pattern you will see is that this latter case
actually only happens in the few cases where NULL is passed as
data to the [devm_]request_irq() registration call, and the driver
does not have a state container at all. I think that is
quite uncommon and mostly happens in legacy code, but I may
be wrong....
I think we have a big bunch of cleanups to do wrt this, in my book
devm_request_irq() is considered harmful from now on, thanks for
putting this in the spotlight.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
