On Thu, Mar 29, 2018 at 02:07:51PM -0700, Nathan Chancellor wrote:
> 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.
>
Personally I would prefer a revert as well. I am going to do that for the merge
of v4.4.124 into chromeos-4.4. Everything else adds just too much risk at this
point.
Guenter
> >
> > 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