Hi Marc,
On Thu, Jan 17, 2019 at 11:32:01AM +0000, Marc Zyngier wrote:
> > static int pmic_gpio_to_irq(struct gpio_chip *chip, unsigned pin)
> > {
> > struct pmic_gpio_state *state = gpiochip_get_data(chip);
> > - struct pmic_gpio_pad *pad;
> > + struct irq_fwspec fwspec;
> >
> > - pad = state->ctrl->desc->pins[pin].drv_data;
> > + fwspec.fwnode = state->fwnode;
> > + fwspec.param_count = 2;
> > + fwspec.param[0] = pin + PMIC_GPIO_PHYSICAL_OFFSET;
> > + fwspec.param[1] = IRQ_TYPE_NONE;
>
> In my experience, IRQ_TYPE_NONE is rarely a good thing, unless you
> expect the trigger information to be found by some other mean. I guess
> that's one of the reasons why everything falls back to level in the SPMI
> driver...
I'm not sure how to determine what trigger to put here. I thought that
it would be up to the caller of request_any_context_irq() to explicitly
set the expected trigger type when a GPIO is used, which will overwrite
IRQ_TYPE_NONE with the proper trigger type.
For example, I've tested the hierarchical IRQ domains with gpio-keys and
when the gpio property is used, devm_request_any_context_irq() is called
with the flags IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING. This calls
__setup_irq(), which will call irq_set_type() and overwrite the trigger
type.
irq_set_type() is only called when the IRQ is not shared, so I'm not
sure if this would work as expected with a shared IRQ.
Brian
