[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <88524db5-cda6-4529-83db-54ff3b3d5819@oracle.com>
Date: Thu, 5 Feb 2026 22:09:45 +0530
From: Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
David Lechner
<dlechner@...libre.com>,
Nuno Sá <nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>,
Antoniu Miclaus <antoniu.miclaus@...log.com>,
Andrew Ijano <andrew.ijano@...il.com>, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH v5 next 2/7] iio: sca3000: switch IRQ handling to devm
helpers
Hi Andy,
On 05/02/26 21:53, Andy Shevchenko wrote:
> On Thu, Feb 05, 2026 at 05:12:08AM -0800, Harshit Mogalapalli wrote:
>> Convert the threaded IRQ registration to devm_request_threaded_irq() so
>> that the probe and remove paths can drop manual freeing of irqs.
>>
>> No functionality change.
>
> ...
>
Thanks for the reviews!
>> -error_free_irq:
>> - if (spi->irq)
>> - free_irq(spi->irq, indio_dev);
>> -
>> - return ret;
>
> ...
>
>> - if (spi->irq)
>> - free_irq(spi->irq, indio_dev);
>
> Do we need an irq member to be in the struct after this patch?
I probably didn't understand that question fully.
we still have a call to ret = devm_request_threaded_irq(dev, spi->irq,
NULL,...) so we can't relaly get rid of the irq member I think, did I
understand your question right ?
Thanks,
Harshit
>
Powered by blists - more mailing lists