| Message ID | 20240731140657.88265-1-francesco@dolcini.it (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v1] iio: adc: ads1119: Fix IRQ flags | expand |
On Wed, Jul 31, 2024 at 04:06:57PM +0200, Francesco Dolcini wrote: > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > Remove IRQF_TRIGGER_FALLING flag from irq request, this should come from > the platform firmware and should not be hard-coded into the driver. > > Add IRQF_ONESHOT flag to the irq request, the interrupt should not be > re-activated in interrupt context, it should be done only after the > device irq handler run. > Reviwed-by: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com>
On Wed, 31 Jul 2024 11:20:16 -0300 João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com> wrote: > On Wed, Jul 31, 2024 at 04:06:57PM +0200, Francesco Dolcini wrote: > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > Remove IRQF_TRIGGER_FALLING flag from irq request, this should come from > > the platform firmware and should not be hard-coded into the driver. > > > > Add IRQF_ONESHOT flag to the irq request, the interrupt should not be > > re-activated in interrupt context, it should be done only after the > > device irq handler run. > > > > Reviwed-by: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com> For the direction, there is a risk that we will break someone who has a firmware that isn't setting this correctly. I don't mind doing that if we have another board that needs control (and is setting it appropriately) though. Is that true here, or is this just cleanup? If it's cleanup we tend to leave these alone (but not introduce them into new code!) Jonathan
Hello Jonathan, On Sat, Aug 03, 2024 at 12:21:27PM +0100, Jonathan Cameron wrote: > On Wed, 31 Jul 2024 11:20:16 -0300 > João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com> wrote: > > > On Wed, Jul 31, 2024 at 04:06:57PM +0200, Francesco Dolcini wrote: > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > Remove IRQF_TRIGGER_FALLING flag from irq request, this should come from > > > the platform firmware and should not be hard-coded into the driver. > > > > > > Add IRQF_ONESHOT flag to the irq request, the interrupt should not be > > > re-activated in interrupt context, it should be done only after the > > > device irq handler run. > > > > > > > Reviwed-by: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com> > > For the direction, there is a risk that we will break someone who > has a firmware that isn't setting this correctly. > I don't mind doing that if we have another board that needs control > (and is setting it appropriately) though. Is that true here, or is > this just cleanup? > > If it's cleanup we tend to leave these alone (but not introduce them > into new code!) The driver was just introduced by me in v6.11, I assume that the only user is a board that is not yet available in the upstream Linux kernel (we gonna send the DT soon), with that said I am relatively confident we are not going to break any user. The reason for sending this patch is that we just stumbled across a different driver that was hard-coding the IRQ flags and it was not working for our hardware, at that moment I realized that the decision on the just added ti-ads1119 was not the best one. The idea of this patch is to clean this up _before_ any user is affected. Francesco
On Sat, 3 Aug 2024 14:12:52 +0200 Francesco Dolcini <francesco@dolcini.it> wrote: > Hello Jonathan, > > On Sat, Aug 03, 2024 at 12:21:27PM +0100, Jonathan Cameron wrote: > > On Wed, 31 Jul 2024 11:20:16 -0300 > > João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com> wrote: > > > > > On Wed, Jul 31, 2024 at 04:06:57PM +0200, Francesco Dolcini wrote: > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > > > Remove IRQF_TRIGGER_FALLING flag from irq request, this should come from > > > > the platform firmware and should not be hard-coded into the driver. > > > > > > > > Add IRQF_ONESHOT flag to the irq request, the interrupt should not be > > > > re-activated in interrupt context, it should be done only after the > > > > device irq handler run. > > > > > > > > > > Reviwed-by: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com> > > > > For the direction, there is a risk that we will break someone who > > has a firmware that isn't setting this correctly. > > > I don't mind doing that if we have another board that needs control > > (and is setting it appropriately) though. Is that true here, or is > > this just cleanup? > > > > If it's cleanup we tend to leave these alone (but not introduce them > > into new code!) > > The driver was just introduced by me in v6.11, I assume that the only > user is a board that is not yet available in the upstream Linux kernel > (we gonna send the DT soon), with that said I am relatively confident we > are not going to break any user. ah! I'd missed the timeline detail completely. Too many drivers and they all have similar names :) > > The reason for sending this patch is that we just stumbled across > a different driver that was hard-coding the IRQ flags and it was not working > for our hardware, at that moment I realized that the decision on the just > added ti-ads1119 was not the best one. > > The idea of this patch is to clean this up _before_ any user is > affected. > Excellent. Applied to the fixes-togreg branch of iio.git. Thanks, Jonathan > Francesco >
diff --git a/drivers/iio/adc/ti-ads1119.c b/drivers/iio/adc/ti-ads1119.c index 630f5d5f9a60..d649980479e4 100644 --- a/drivers/iio/adc/ti-ads1119.c +++ b/drivers/iio/adc/ti-ads1119.c @@ -735,7 +735,7 @@ static int ads1119_probe(struct i2c_client *client) if (client->irq > 0) { ret = devm_request_threaded_irq(dev, client->irq, ads1119_irq_handler, - NULL, IRQF_TRIGGER_FALLING, + NULL, IRQF_ONESHOT, "ads1119", indio_dev); if (ret) return dev_err_probe(dev, ret,