Re: [PATCH v4 0/5] pinctrl/GPIO driver for Apple SoCs
From: Marc Zyngier <maz@kernel.org>
Date: 2021-10-25 10:28:15
Also in:
linux-gpio
On Sun, 24 Oct 2021 11:18:33 +0100, Joey Gouly [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Hi all, Here is the v4 patchset for the Apple pinctrl/GPIO driver. Changes since v3 [1]: - Applied Marc Zyngier's review/patch (with exception noted below) - Removed "apple,t8103-pinctrl" compatible from driver - Applied Acks/Review tags With Marc's changes, the irq_chip was being shared between pinctrl drivers and I was getting the following warning: drivers/gpio/gpiolib.c:1456: detected irqchip that is shared with multiple gpiochips: please fix the driver. So I applied the following diff to Marc's change, to not share the irq_chips, while still being cleaner overall:diff --git a/drivers/pinctrl/pinctrl-apple-gpio.cb/drivers/pinctrl/pinctrl-apple-gpio.c index 732c347a2bbc..ce037a5c15c1 100644--- a/drivers/pinctrl/pinctrl-apple-gpio.c +++ b/drivers/pinctrl/pinctrl-apple-gpio.c@@ -35,6 +35,7 @@ struct apple_gpio_pinctrl { struct pinctrl_desc pinctrl_desc; struct gpio_chip gpio_chip; + struct irq_chip irq_chip; u8 irqgrps[0]; };@@ -369,6 +370,8 @@ static int apple_gpio_gpio_register(structapple_gpio_pinctrl *pctl) return dev_err_probe(pctl->dev, -ENODEV, "No gpio-controller property\n"); + pctl->irq_chip = apple_gpio_irqchip; + pctl->gpio_chip.label = dev_name(pctl->dev); pctl->gpio_chip.request = gpiochip_generic_request; pctl->gpio_chip.free = gpiochip_generic_free;@@ -385,7 +388,7 @@ static int apple_gpio_gpio_register(structapple_gpio_pinctrl *pctl) if (girq->num_parents) { int i; - girq->chip = &apple_gpio_irqchip; + girq->chip = &pctl->irq_chip; girq->parent_handler = apple_gpio_gpio_irq_handler; girq->parents = kmalloc_array(girq->num_parents, Marc said that hierarchical IRQ domains should solve this problem, but I'll let him explain more on the list, maybe that should solved in a different patch series.
The issue I have with the gpiolib code is that it hijacks function pointers from a structure that is not under its control, and that is exactly what the hierarchical IRQ domains/irqchips were supposed to prevent. It isn't obvious to me why this cannot be fixed with a gpiolib domain and irqchip stacked on top of the one exposed by the low-level driver, providing the required hooks in a standard way. Yes, this is even more indirection. It also isn't clear why gpiochip_set_irq_hooks() shouts: if the hooks are already there, move on. Ultimately, this sort of manipulation is what prevents the irq_chip structure from being made 'const' everywhere (ok, there is another nit because of the parent_device field, which I'm looking at getting rid of). Keeping writable function pointers isn't great, overall. Now, given that this is an issue that isn't directly related to the driver at hand, it shouldn't be a blocker for merging it. So for the driver itself: Reviewed-by: Marc Zyngier <maz@kernel.org> M. -- Without deviation from the norm, progress is not possible.