Quoting Douglas Anderson (2021-01-08 09:35:14) > When the Qualcomm pinctrl driver wants to Ack an interrupt, it does a > read-modify-write on the interrupt status register. On some SoCs it > makes sure that the status bit is 1 to "Ack" and on others it makes > sure that the bit is 0 to "Ack". Presumably the first type of > interrupt controller is a "write 1 to clear" type register and the > second just let you directly set the interrupt status register. > > As far as I can tell from scanning structure definitions, the > interrupt status bit is always in a register by itself. Thus with > both types of interrupt controllers it is safe to "Ack" interrupts > without doing a read-modify-write. We can do a simple write. > > It should be noted that if the interrupt status bit _was_ ever in a > register with other things (like maybe status bits for other GPIOs): > a) For "write 1 clear" type controllers then read-modify-write would > be totally wrong because we'd accidentally end up clearing > interrupts we weren't looking at. > b) For "direct set" type controllers then read-modify-write would also > be wrong because someone setting one of the other bits in the > register might accidentally clear (or set) our interrupt. > I say this simply to show that the current read-modify-write doesn't > provide any sort of "future proofing" of the code. In fact (for > "write 1 clear" controllers) the new code is slightly more "future > proof" since it would allow more than one interrupt status bits to > share a register. > > NOTE: this code fixes no bugs--it simply avoids an extra register > read. > > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > --- Reviewed-by: Stephen Boyd <swboyd@xxxxxxxxxxxx>
