On Sun, 24 Oct 2021 11:18:33 +0100,
Joey Gouly <joey.gouly@xxxxxxx> wrote:
>
> 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.c
> b/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(struct
> apple_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(struct
> apple_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@xxxxxxxxxx>
M.
--
Without deviation from the norm, progress is not possible.
