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]

Date:   Mon, 7 Nov 2016 13:32:45 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Marc Zyngier <marc.zyngier@....com>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        <linux-kernel@...r.kernel.org>
Subject: Re: BUG? genirq: irq 14 uses trigger mode 8; requested 0

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.

Cheers
Jon

-- 
nvpublic