Hi Greg,
On Thu, Mar 29, 2018 at 10:54:34AM -0700, Guenter Roeck wrote:
On Thu, Mar 29, 2018 at 08:32:01AM +0200, Greg Kroah-Hartman wrote:
On Wed, Mar 28, 2018 at 02:59:18PM -0700, Guenter Roeck wrote:
Hi Greg,
commit 9d0273bb1c4b64 ("genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs") causes a regression in v4.4.124. The problem has been fixed upstream with commit 4f8413a3a799 ("genirq: Track whether the trigger type has been set"). Please apply that patch to v4.4.y at your earliest convenience.
The patch does not apply cleanly; you'll get a conflict include/linux/irq.h. The fix is simple - just take the version introduced by the patch. It adds a couple of extra defines, but those don't hurt and just keep the code aligned with upstream.
Thanks, this was also needed for 4.9.y and 3.18.y.
Odd that I didn't see the problem there. But then I still see the following in 4.4.y after the above was added.
genirq: Flags mismatch irq 24. 00000080 ([PCI] PME) vs. 00000080 ([EDAC] PCI err)
This is with powerpc:mpc8544ds:mpc85xx_defconfig. I do _not_ see this problem in v4.9+.
Looks like I'll need to spend more time on this.
I confirmed that this is still broken in 4.4.y, even after 4f8413a3a799 has been applied.
Example output on a Acer 15.6" APL Chromebook, with both patches applied:
[ 0.240913] gpiochip_find_base: found new base at 434 [ 0.240956] gpiochip_add_data: registered GPIOs 434 to 511 on device: INT3452:00 [ 0.240960] GPIO chip INT3452:00: created GPIO range 0->77 ==> INT3452:00 PIN 0->77 [ 0.241311] gpiochip_find_base: found new base at 357 [ 0.241347] gpiochip_add_data: registered GPIOs 357 to 433 on device: INT3452:01 [ 0.241350] GPIO chip INT3452:01: created GPIO range 0->76 ==> INT3452:01 PIN 0->76 [ 0.241353] genirq: Flags mismatch irq 14. 00000080 (INT3452:01) vs. 00000080 (INT3452:00) [ 0.242055] broxton-pinctrl INT3452:01: failed to request interrupt [ 0.242696] broxton-pinctrl: probe of INT3452:01 failed with error -16 [ 0.243452] gpiochip_find_base: found new base at 387 [ 0.243490] gpiochip_add_data: registered GPIOs 387 to 433 on device: INT3452:02 [ 0.243493] GPIO chip INT3452:02: created GPIO range 0->46 ==> INT3452:02 PIN 0->46 [ 0.243496] genirq: Flags mismatch irq 14. 00000080 (INT3452:02) vs. 00000080 (INT3452:00) [ 0.244195] broxton-pinctrl INT3452:02: failed to request interrupt [ 0.244813] broxton-pinctrl: probe of INT3452:02 failed with error -16 [ 0.245549] gpiochip_find_base: found new base at 391 [ 0.245585] gpiochip_add_data: registered GPIOs 391 to 433 on device: INT3452:03 [ 0.245588] GPIO chip INT3452:03: created GPIO range 0->42 ==> INT3452:03 PIN 0->42 [ 0.245591] genirq: Flags mismatch irq 14. 00000080 (INT3452:03) vs. 00000080 (INT3452:00) [ 0.246322] broxton-pinctrl INT3452:03: failed to request interrupt [ 0.246912] broxton-pinctrl: probe of INT3452:03 failed with error -16
Reverting 9d0273bb1c4b64 after the v4.4.124 merge into chromeos-4.4 fixes the problem.
At this point I got a bit frantic and decided to try the shotgun approach. I applied
4b357daed698 genirq: Look-up trigger type if not specified by caller f35ad083783e genirq: Look-up percpu trigger type if not specified by caller 00b992deaa08 genirq: No need to mask non trigger mode flags before __irq_set_trigger() 7ee7e87dfb15 genirq: Use irq type from irqdata instead of irqdesc (minor conflicts due to pr_warning -> pr_warn)
on top of v4.4.124. With those patches applied, the problem went away, both on the Acer Chromebook and the qemu test which previously failed. Note that I have _no_ idea if this is correct, necessary, and/or complete. All I know is that it fixes the problems I have found so far.
Overall question is why 9d0273bb1c4b64 was applied to v4.4.y in the first place. It does cause a whole lot of trouble. Was that really worth it ?
Guenter