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 11:10 AM, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> 
> Note that usually, the bus acquire / release issue is not a problem
> if there's a single slave on the bus, which remains the common case.

It might be a common case on x86, but it is definitely not the common case on ARM.

>> [...]
>>> 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.
> 
> Sure, I agree with this long-term goal. Beside ihidev I have another case
> that would use it (on arm).
> 
> But this is lots of work, and we can't break existing code until all
> ports have implemented it.

Well, the current ihidev really only works on x86 anyway, because it depends on ACPI.  Yes, I know that aarch64 has ACPI, but I don't know if any such systems where i2c hid would be applicable at the moment (the i2c hid driver does not currently support FDT, which would be the more common way for i2c hid to be used on ARM right now anyway).

I suppose with my current set of changes, ihidev would be broken on a XEN Dom0 system.  How common would that scenario be?  Anyway, I'd argue that the current situation is equally broken, and I've already been waiting for 4 months for someone who understands the XEN interrupt code to help out with this.  Am I supposed to just wait indefinitely?

-- thorpej