On Thu, Mar 29, 2018 at 02:45:15PM -0700, Guenter Roeck wrote:
> 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.
Yeah, I'll just do a revert. Give me a few hours and I'll push out -rc2
releases with this change in them.
thanks,
greg k-h