On Thu, Mar 21, 2019 at 10:54 PM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > Quoting Marc Zyngier (2019-03-16 04:39:48)> > On Fri, 15 Mar 2019 09:28:31 -0700 > > Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > > > > > Quoting Lina Iyer (2019-03-13 14:18:41) > > > > @@ -994,6 +1092,22 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl) > > > > pctrl->irq_chip.irq_request_resources = msm_gpio_irq_reqres; > > > > pctrl->irq_chip.irq_release_resources = msm_gpio_irq_relres; > > > > > > > > + chip->irq.chip = &pctrl->irq_chip; > > > > + chip->irq.domain_ops = &msm_gpio_domain_ops; > > > > + chip->irq.handler = handle_edge_irq; > > > > + chip->irq.default_type = IRQ_TYPE_EDGE_RISING; > > > > > > This also changed from v3. It used to be IRQ_TYPE_NONE. Specifying this > > > here seems to cause gpiolib to print a WARN. > > > > > > > > > /* > > > * Specifying a default trigger is a terrible idea if DT or ACPI is > > > * used to configure the interrupts, as you may end up with > > > * conflicting triggers. Tell the user, and reset to NONE. > > > */ > > > if (WARN(np && type != IRQ_TYPE_NONE, > > > "%s: Ignoring %u default trigger\n", np->full_name, type)) > > > type = IRQ_TYPE_NONE; > > > > > > > > > So I guess this change should be dropped. Or at the least, it should be > > > split out to it's own patch and the motivations can be discussed in the > > > commit text. > > > > It is something I requested (although I expected this to be a > > different patch, and even a clarification would have been OK). > > > > One way or another, the default trigger must match the flow handler. If > > we set it up with IRQ_TYPE_NONE, what does it mean? The fact that > > IRQ_TYPE_NONE acts as a wildcard doesn't mean the handle_edge_irq flow > > handler is a good match for all interrupt types (it is rarely OK for > > level interrupts). > > I think this is a question for Thierry or Linus. I'm not sure why this > check was put in place in the code. I tried to dig into it really quick > but I didn't find anything obvious and then I gave up. > > Maybe with hierarchical irqdomains we can drop this check? I don't think > the gpiolib core ever uses this 'default_type' or 'handler' for anything > once we replace the irqdomain that's used for a particular gpiochip with > a custom irqdomain. The only user I see, gpiochip_irq_map(), won't ever > be called so it really ends up being a thing that the driver specific > irqdomains should check for and reject when parsing the DT and it sees > IRQ_TYPE_NONE come out. > > ------8<------- > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index 144af0733581..fe2f7888c473 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -1922,7 +1922,7 @@ static int gpiochip_add_irqchip(struct gpio_chip *gpiochip, > * used to configure the interrupts, as you may end up with > * conflicting triggers. Tell the user, and reset to NONE. > */ > - if (WARN(np && type != IRQ_TYPE_NONE, > + if (WARN(!gpiochip->irq.domain_ops && np && type != IRQ_TYPE_NONE, > "%s: Ignoring %u default trigger\n", np->full_name, type)) > type = IRQ_TYPE_NONE; Sorry for taking long time to answer... this got lost in some mail storms. It's a bit of Marc Z question really but I try to answer and he can correct me. We are now getting used to ACPI and DT always specifying the IRQ trigger type on the consumer handle: a device tells the irqchip what kind of edge or level it wants. Things weren't always like that. Some boards in the kernel is still using board files. (Yeah please help in modernizing them, I am doing my part.) Old machines with GPIO irqchip jitted to the SoC irq controller sometimes had a hardcoded behavior such as edge, and the consumers would only issue something really legacy like request_irq(42, myhandler, 0, "myirq", data); and expect it to work, since 0 means use the default flags, it might have a platform device with this irq number passed as a resource, but that is a really dumb platform device still, and it might not have set any irqflags for the irq number it passes. It probably doesn't even know that the irq number is backed by an irq descriptor. Since the code that e.g. DT has inside drivers/of/platform.c irq_of_parse_and_map(), will incidentally create an irq descriptor and set up these flags from the consumer flags in the device tree and call the irqchip to set up the trigger through .set_type() whenever the interrupt is requested, this is no problem for DT. Or ACPI. But on a board file, the .set_type() will eventually be called with IRQ_TYPE_NONE, which will cause a bug, or no IRQs or something like that. So a bunch of GPIO irqchips are created passing IRQ_TYPE_EDGE_* or IRQ_TYPE_LEVEL_* to set up a default trigger, because all the irqs on this chip use the same trigger anyway, and they only have one flow handler anyway. Everything is edge, or everything is level or so. irq_set_irq_type() will be called when mapping the GPIO to an irq, including calls from gpiod_to_irq() and friends that get used a lot in legacy code. This happened by simply factoring custom GPIO irqchips into the gpiolib over time. No-one has really gotten around to tracking down all the offending callers of request_irq() and their respective interrupt providers and make sure the descriptors for all these IRQs get set up properly in drivers or board files. As far as I know. (INTERESTING WORK!) It is a mess, really hard to fix, essentially everything need to be modernized or deleted for us to get rid of the possibility to pass a default trigger. I guess it is possible to check all gpiochip_irqchip_add* and see if there are still chips passing something else than IRQ_TYPE_NONE. It would take some time to look at all of them, maybe it isn't used by anything anymore? Then we can simply delete this and assume it will always be set up orderly. We have modernized quite a few systems recently. Yours, Linus Walleij
