Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..'

Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..'

[Guenter Roeck]

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,
Guenter

Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..'

[Greg Kroah-Hartman]

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.

greg k-h

Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..'

[Guenter Roeck]

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.

Guenter

Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..'

[Guenter Roeck]

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

Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..'

[Nathan Chancellor]

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

Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..'

[Guenter Roeck]

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

Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..'

[Greg Kroah-Hartman]

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

Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..'

[Greg Kroah-Hartman]

On Fri, Mar 30, 2018 at 08:26:07AM +0200, Greg Kroah-Hartman wrote:
> 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.

Now reverted and pushed out.

thanks,

greg k-h