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?
Thanks for the detailed description. Cheers Jon -- nvpublic
