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@xxxxxxxxx> wrote: > > > On Wed, Jul 31, 2024 at 04:06:57PM +0200, Francesco Dolcini wrote: > > > From: Francesco Dolcini <francesco.dolcini@xxxxxxxxxxx> > > > > > > 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@xxxxxxxxx> > > 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
