Re: [PATCH] Add intr_mask() / intr_unmask() interface to mask / unmask individual interrupt sources

[Jason Thorpe <thorpej%me.com@localhost>]

> On Nov 30, 2019, at 10:02 AM, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> 
> This depends on the backend controller. iichid on x86 is working fine
> as is on my laptop ...

It might "work" in some cases, but is in general not a safe model.  Saying it "depends on the backend controller" is really a giant red flag, complete with <blink> tag and klaxons sounding off.  As I was cleaning up the way the i2c mid-layer handles bus acquire / release, I found wildly inconsistent behavior... some back-end controllers didn't even bother with the bus lock if I2C_F_POLL was specified and would have happily clobbered on whatever else might have been going on at the time.  Others would have deadlocked.  Still others would have done things that would have resulted in a panic.  In at least one case, I found a bug in a backend driver that required it to force I2C_F_POLL because **without it** a deadlock was guaranteed.

All of this harmonized with my i2c-cleanup changes, the behavior is consistent across every controller type, a bunch of code is removed (because bus acquire / release logic is handled by the mid-layer), and some drivers are now able to eliminate a bunch of busy-waiting they previously had to do.

Unfortunately, hid-over-i2c has a very dumb interrupt specification (level-sensitive).  Edge-sensitive would have been much more appropriate for this sort of device and would have eliminated the need for the mask/unmask stuff in there first place (at least for this use case).  "Luckily", not everyone follows the spec... at least, I've seen a few device trees where the interrupt is edge-triggered, and the patch I wrote for ihidev.c supports an edge-sensitive interrupt.

> I still believe we'll need some #define to know if the MD interrupt code
> provides working mask/unmask until all ports provide them.
> This will be usefull for more hardware than i2c ...

I guess I'm fine with adding a #define __HAVE_INTR_MASK that can be tested (and I'll make ihidev.c require it).

But eventually a proper overhaul of the various interrupt APIs we have needs to be undertaken.  Alas, that's just beyond the scope of what I'm trying to get done right now, and I don't really have the bandwidth to go down that rabbit hole.

-- thorpej