> > >Hi, > >Pawel Laszczak <paw...@cadence.com> writes: >>>>>> IRQF_ONESHOT can be used only in threaded handled. >>>>>> " >>>>>> * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler >>>>>> finished. >>>>>> * Used by threaded interrupts which need to keep the >>>>>> * irq line disabled until the threaded handler has been >>>>>> run. >>>>>> " >>>>> >>>>>so? >>>> >>>> I don't understand why If I don't have threaded handler why I need >>>> IRQF_ONESHOT. >>>> Why interrupt cannot be reenabled after hardirq handler finished ? >>>> I do not use threaded handler so this flag seem unnecessary. >>> >>>Unless this has changed over the years, it was a requirement from IRQ >>>susbystem. >>> >>> /* >>> * Drivers are often written to work w/o knowledge about the >>> * underlying irq chip implementation, so a request for a >>> * threaded irq without a primary hard irq context handler >>> * requires the ONESHOT flag to be set. Some irq chips like >>> * MSI based interrupts are per se one shot safe. Check the >>> * chip flags, so we can avoid the unmask dance at the end of >>> * the threaded handler for those. >>> */ >>> if (desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE) >>> new->flags &= ~IRQF_ONESHOT; >> >> From description I understand that it should be set when driver uses only >> threaded handler without hard irq handler. >> eg. >> >> ret = devm_request_threaded_irq(dev, data->usb_id_irq, >> NULL, int3496_thread_isr, >> IRQF_SHARED | IRQF_ONESHOT | >> IRQF_TRIGGER_RISING | >> IRQF_TRIGGER_FALLING, >> dev_name(dev), data); >> >> It make sense, we don't have hard irq handler so we can't clear source of >> interrupt. >> If we clear it immediately in interrupt controller then the same interrupt >> could >> be raised again, because it was not cleared e.g in controller register. > >You are correct. Big mistake on my side. Apologies.
All right, you're welcome. I learn a lot of during such discussions :). >-- >balbi
