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
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
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
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
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
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
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
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
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
Guenter Roeck -
Nathan Chancellor