Hi Bobby, On Tue, Feb 12, 2019 at 9:17 PM Robert Eshleman <bobbyeshleman@xxxxxxxxx> wrote: > > First, thank you for the feedback. First of all, thank _you_ for doing the hard work on this driver ! I very much respect what you've done here. > > I had initially went with a similar design, but there is > the case in which the interrupt fires and then before the status > register is read by the handler a user process reads the data and > clears the interrupt. When the handler continues execution it will > read a zero status and return IRQ_NONE. My understanding of how > Linux handles IRQ_NONE is pretty poor, but I felt that this behavior > is incorrect even if inconsequential. This could be avoided by > doing a status register read with every data read, and buffering > that as well, but then we lose the benefit altogether by increasing > I2C reads. > > In the approach you describe here, it seems like that would > work if this driver wasn't supporting shared interrupts. In the > case that a user-space read happens to clear the interrupt before > the handler reads the status register, I think we would end up > falsely returning IRQ_NONE. > > Is my understanding of this correct? It's very possible I'm > misunderstanding IRQ_NONE and shared interrupts. > Yes, I can see how one can run into those issues. I believe that this whole class of problems goes away if PS/ALS are _exclusively_ read inside the interrupt, and cached. Then, whenever a user process wants to read the data, the function does not touch the h/w, but simply return the cached value. But hang on, I will have more to say on this when replying to Jonathan's feedback.
