Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> writes:
> On Fri, Jan 03, 2020 at 11:02:40AM -0300, Guilherme G. Piccoli wrote:
>> This patch changes this behavior by preventing shared interrupts if the
>> HPET-based IRQ handler is used instead of the regular cmos_interrupt()
>> one. Although "irqpoll" is not a default kernel option, it's used in
>> some contexts, one being the kdump kernel (which is an already "impaired"
>> kernel usually running with 1 CPU available), so the performance burden
>> could be considerable. Also, the same issue would happen (in a shorter
>> extent though) when using "irqfixup" kernel option.
...
>> Hi all, thanks for reading/reviewing this patch! One of the
>> alternatives I considered in case sharing interrupts are really
>> desirable is a new kernel parameter to rtc-cmos to allow
>> sharing interrupts, and default the IRQ setup to non-shared.
>>
>> We could also disable sharing if "irqpoll" or "irqfixup" is set,
>> but this would somewhat "bypass" IRQ code API which I think would
>> be a bit ugly.
>>
>> Please let me know your thoughts, and thanks in advance.
>
> I think you may ask for Thomas' opinion (Cc'ed now).
I'm a bit wary with binding this to the fact that the HPET is
involved.
Especially I don't know whether the Surface3 which is Intel based
exposes the HPET via ACPI which would pretty much revert the effect of
the mentioned commit which introduced the IRQF_SHARED magic especially
for Surface3.
As this is a Surface3 specific misfeature, it might be trivial enough to
set IRQF_SHARED based on a DMI quirk for the Surface3.
Thanks,
tglx
