Re: Failed IRQ assignment for INT0002 on Braswell

[Oleksandr Natalenko]

Hi, Hans.

On stÅeda 22. listopadu 2017 11:48:50 CET Hans de Goede wrote:
> /* snip */
> This should be fixed by:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ke
> rnel/irq?id=382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7
> 
> Which is in 4.13, but the trigger-type does not seem to be the problem in
> your case, the problem likely is the ONESHOT flag:
> 
> #define IRQF_ONESHOT            0x00002000
> 
> Which appears to be set in the flags for the acpi irq handler:
>  > kernel: genirq: Flags mismatch irq 9. 00010084 (INT0002) vs. 00002080
>  > (acpi)
> But that irq is requested here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv
> ers/acpi/osl.c#n570
> 
> 
> 
> 	if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) {
> 		printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq);
> 		...
> 
> And IRQF_ONESHOT is not passed, so I do not understand where the 00002000 in
> the acpi irq handler flags is coming from ...

Well, looks like I know where this flag comes from. I boot this machine with 
"threadirqs", and IRQF_ONESHOT description says:

===
 52  * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler 
finished.
 53  *                Used by threaded interrupts which need to keep the
 54  *                irq line disabled until the threaded handler has been 
run.
===

If I boot the machine without "threadirqs", looks like the device is set up 
okay. The only message I get in the kernel log is:

===
kernel: acpi INT0002:00: Device [GPED] is in always present list
===

Grepping for IRQ 9:

===
kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
kernel: ACPI: IRQ9 used by override.
===

and 9th interrupt shows this device:

===
   9:          0          0          0          0   IO-APIC    9-fasteoi   
acpi, INT0002
===

Any idea why "threadirqs" makes this fail?

Thanks.

Regards,
  Oleksandr