Hi,
On 30-10-2019 15:47, Andy Shevchenko wrote:
On Wed, Oct 30, 2019 at 02:11:50PM +0100, Hans de Goede wrote:
On 30-10-2019 13:42, Linus Walleij wrote:
On Wed, Oct 30, 2019 at 10:31 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
TL;DR: commit 88583e340a0e ("pinctrl: intel: baytrail: Pass irqchip when adding gpiochip")
breaks a bunch of stuff and should be dropped from pinctrl/intel.git/for-next
and this needs some more work before it is ready for mainline.
I don't know if that is such a good idea if this is a global problem,
like something that would potentially disturb any ACPI-based
GPIO chip. We might leave something else broken even if we
fix the issue locally.
Right, I did a quick check and at least these x86 pinctrl drivers
all 3 have this ordering problem once the irq chip registration is
moved to the gpiochip_add_data() call.
drivers/pinctrl/intel/pinctrl-baytrail.c
drivers/pinctrl/intel/pinctrl-cherryview.c
drivers/pinctrl/intel/pinctrl-intel.c
drivers/pinctrl/pinctrl-amd.c
Hmm.. do we have cherryview broken in next / vanilla?
In 5.4-rc# the irq chip is still registered as a separate step
after the gpiochip_add_pin_range calls.
I'm also not seen any troublesome patches here:
https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git/log/?h=for-next
And it seems that drivers/gpio/gpio-merrifield.c is already
suffering from this problem in 5.4!
So some more generic solution would be ideal...
merrifield OTOH definitely seems broken wrt this (when looking at the code).
Regards,
Hans
