linux-kernel - Re: BUG? genirq: irq 14 uses trigger mode 8; requested 0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f721714f-f1dc-982a-8acd-21f24f67d1c6@arm.com>
Date:   Mon, 7 Nov 2016 14:40:47 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     Jon Hunter <jonathanh@...dia.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: BUG? genirq: irq 14 uses trigger mode 8; requested 0

On 07/11/16 13:32, Jon Hunter wrote:
> Hi Mika,
> 
> On 07/11/16 11:49, Mika Westerberg wrote:
>> On Tue, Nov 01, 2016 at 04:44:00PM +0200, Mika Westerberg wrote:
>>> On Tue, Nov 01, 2016 at 02:24:38PM +0000, Jon Hunter wrote:
>>>> Hi Mika,
>>>>
>>>> On 01/11/16 13:02, Mika Westerberg wrote:
>>>>> Hi,
>>>>>
>>>>> I started seeing following messages on Intel Broxton when the
>>>>> pinctrl/GPIO driver [1] loads:
>>>>>
>>>>>   [    0.645786] genirq: irq 14 uses trigger mode 8; requested 0
>>>>>
>>>>> The driver shares interrupt with other GPIO "communities" or banks so it
>>>>> uses request_irq() instead of irq_set_chained_handler_and_data(). The
>>>>> driver does not specify IRQ flags as those come from ACPI resources.
>>>>>
>>>>> This started happen after commit 4b357daed698 ("genirq: Look-up trigger
>>>>> type if not specified by caller").
>>>>>
>>>>> I think this is what happens:
>>>>>
>>>>>   1. ACPI platform sets up the interrupt according what is in the _CRS
>>>>>   of the GPIO device. This ends up setting trigger type for irq_data of
>>>>>   the irq.
>>>>>
>>>>>   2. First GPIO device is found and the driver calls request_irq() which
>>>>>   calls __setup_irq() where shared == 0.
>>>>>
>>>>>   3. Since new->flags is read back from irq_data we call __irq_set_trigger()
>>>>>   passing the flags.
>>>>>
>>>>>   4. The parent IRQ chip, IO-APIC, does not have ->irq_set_type callback
>>>>>   so __irq_set_trigger() never calls irq_settings_set_trigger_mask() for
>>>>>   the desciptor.
>>>>>
>>>>>   5. The second GPIO device is found and this time shared == 1 so we
>>>>>   end up comparing nmsk with omsk where nmsk was read from irq_data
>>>>>   and omsk is read using irq_settings_get_trigger_mask().
>>>>>
>>>>>   6. Because we never called irq_settings_set_trigger_mask() for the
>>>>>   descriptor, omsk is 0 and we print out a warning:
>>>>>
>>>>>   [    0.645786] genirq: irq 14 uses trigger mode 8; requested 0
>>>>>
>>>>> If I revert commit 4b357daed698 the warning goes away.
>>>>>
>>>>> Do you have any ideas how to get rid of the warning properly?
>>>>
>>>> May be I am misunderstanding something here, but if the parent does not have
>>>> a ->irq_set_type callback, then it would seem that the type for the
>>>> interrupt should be not specified/set in the ACPI _CRS for the GPIO device,
>>>> right?
>>>
>>> Not sure.
>>>
>>> Why the parent driver (IO-APIC) does not have ->irq_set_type callback is
>>> beyond me. I guess it might have something to do with the IRQ hierarchy
>>> domains it is part of.
>>>
>>> When the ACPI core parses _CRS for the GPIO device it calls
>>> acpi_register_gsi() with the triggering flags from _CRS and that ends up
>>> calling acpi_register_gsi_ioapic() that programs the hardware
>>> accordingly. So we definitely need to have the type in _CRS.
>>
>> Jon, Marc, 
>>
>> Do you have any suggestions how to fix this other than reverting
>> 4b357daed698 ("genirq: Look-up trigger type if not specified by
>> caller")?
>>
>> Before that commit everything works fine.
> 
> Sorry I forgot to respond again last week.
> 
> Marc, what do you think? Feels to me that this parent should have a
> ->irq_set_type callback even if it is just a dummy one and does nothing.

Sorry, missed this discussion entirely, as I was on the other side of
the world. Not having a irq_set_type definitely seems odd (and 
configuring the trigger outside of the IRQ framework is quite ugly).

Mika, can you please try the following (which is fully untested)?

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 48e6d84..822a6b8 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1868,6 +1868,15 @@ static int ioapic_set_affinity(struct irq_data *irq_data,
 	return ret;
 }
 
+static int ioapic_set_type(struct irq_data *data, unsigned int flow_type)
+{
+	/*
+	 * The IOAPIC has already been programmed behind our back,
+	 * just pretend it all went OK, and too bad if it didn't.
+	 */
+	return 0;
+}
+
 static struct irq_chip ioapic_chip __read_mostly = {
 	.name			= "IO-APIC",
 	.irq_startup		= startup_ioapic_irq,
@@ -1876,6 +1885,7 @@ static struct irq_chip ioapic_chip __read_mostly = {
 	.irq_ack		= irq_chip_ack_parent,
 	.irq_eoi		= ioapic_ack_level,
 	.irq_set_affinity	= ioapic_set_affinity,
+	.irq_set_type		= ioapic_set_type,
 	.flags			= IRQCHIP_SKIP_SET_WAKE,
 };
 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...