linux-kernel - Re: [PATCH v5 07/14] qcom: spmi-gpio: add support for hierarchical IRQ chip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190118124221.GB32143@basecamp>
Date:   Fri, 18 Jan 2019 07:42:21 -0500
From:   Brian Masney <masneyb@...tation.org>
To:     Marc Zyngier <marc.zyngier@....com>
Cc:     linus.walleij@...aro.org, sboyd@...nel.org,
        bjorn.andersson@...aro.org, andy.gross@...aro.org,
        shawnguo@...nel.org, dianders@...omium.org,
        linux-gpio@...r.kernel.org, nicolas.dechesne@...aro.org,
        niklas.cassel@...aro.org, david.brown@...aro.org,
        robh+dt@...nel.org, mark.rutland@....com, thierry.reding@...il.com,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v5 07/14] qcom: spmi-gpio: add support for hierarchical
 IRQ chip

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