Thread (13 messages) 13 messages, 4 authors, 2021-10-25

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.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@kernel.org>

	M.

-- 
Without deviation from the norm, progress is not possible.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help