On Thu, Mar 29, 2018 at 01:28:45PM -0700, Guenter Roeck wrote:
> 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.
My guess would be the first one based on the logs and the commit mesage
of 9d0273bb1c4b64. It seems like all five are basically a series so it
should be all or none. I'd say the safer bet would be to revert
9d02733bb1c4b64 since the fact 4b357daed698 hasn't been requested before
means not many devices on 4.4 need that functionality. Just my two cents
which may be totally incorrect.
>
> 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 ?
>
It came in via Sasha's auto selection process: https://lkml.org/lkml/2018/3/8/177
> Guenter