On 5/19/20 6:32 PM, Maarten Brock wrote: > On 2020-05-18 18:57, Daniel Mack wrote: >> It's a controller that sits behind another hardware bus itself, so >> polling is expensive. If the controller would need to check for level >> IRQs it would need to poll, and then we could as well just poll the UART >> directly, that's just as good :) > > That depends on the IRQ coming out of the interrupt controller. If that is > a level interrupt itself, then it is easy to see if all interrupts are > handled. Further polling zooms in on the devices that require attention. Yeah, I'm familiar with the concept, but it's not like that here, unfortunately. >> But again - the UART driver works perfectly fine with edge IRQs as long >> as the interrupt is not shared. > > If you would require multiple sc16is7xx devices on I2C would you like to > connect multiple interrupt lines? Or just SCL,SDA and *one* IRQ? > > OTOH for SPI you would require multiple CS already. Right. Nevertheless, we can allow sharing the IRQ line for level-trigger capable IRQ controllers, you're right. >> What many drivers do is try with one setting, and if that fails because >> the interrupt controller returns an error, they fall back to something >> else. We could do the same here of course, but it'd be another patch on >> top, as it's unrelated to the concrete change the patch we're commenting >> on is bringing in. >> >> So what I can add is logic that first tries with IRQF_LOW|IRQF_SHARED, >> and if that fails, we fall back to IRQF_FALLING and retry. WDYT? > > That sounds like a decent plan. Okay, I'll add a patch to the series then and resend. Thanks for your feedback! Daniel