linux-kernel - Re: [PATCH 1/1] pinctrl: stmfx: add irq_request/release

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: <8eb2090a-e50e-2e4f-982b-073ad24e553c@st.com>
Date:   Mon, 7 Oct 2019 16:53:09 +0200
From:   Amelie DELAUNAY <amelie.delaunay@...com>
To:     Linus Walleij <linus.walleij@...aro.org>
CC:     Alexandre TORGUE <alexandre.torgue@...com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>
Subject: Re: [PATCH 1/1] pinctrl: stmfx: add irq_request/release_resources
 callbacks

Hi Linus,

On 10/5/19 6:49 PM, Linus Walleij wrote:
> On Fri, Oct 4, 2019 at 2:29 PM Amelie Delaunay <amelie.delaunay@...com> 
> wrote:
> 
>> When an STMFX IO is used as interrupt through the interrupt-controller
>> binding, the STMFX driver should configure this IO as input. Default
>> value of STMFX IO direction is input, but if the IO is used as output
>> before the interrupt use, it will not work without these callbacks.
>>
>> Signed-off-by: Amelie Delaunay <amelie.delaunay@...com>
> 
> OK I see what you want to achieve.
> 
>> +static int stmfx_gpio_irq_request_resources(struct irq_data *data)
>> +{
>> +       struct gpio_chip *gpio_chip = irq_data_get_irq_chip_data(data);
>> +       struct stmfx_pinctrl *pctl = gpiochip_get_data(gpio_chip);
>> +       int ret;
>> +
>> +       ret = stmfx_gpio_direction_input(&pctl->gpio_chip, data->hwirq);
>> +       if (ret)
>> +               return ret;
>> +
>> +       ret = gpiochip_lock_as_irq(&pctl->gpio_chip, data->hwirq);
>> +       if (ret) {
>> +               dev_err(pctl->dev, "Unable to lock gpio %lu as IRQ: %d\n",
>> +                       data->hwirq, ret);
>> +               return ret;
>> +       }
>> +
>> +       return 0;
>> +}
> 
> Just call gpiochip_reqres_irq() instead of calling the lock etc
> explicitly.
> 
>> +static void stmfx_gpio_irq_release_resources(struct irq_data *data)
>> +{
>> +       struct gpio_chip *gpio_chip = irq_data_get_irq_chip_data(data);
>> +       struct stmfx_pinctrl *pctl = gpiochip_get_data(gpio_chip);
>> +
>> +       gpiochip_unlock_as_irq(&pctl->gpio_chip, data->hwirq);
>> +}
> 
> Just call gpiochip_relres_irq()
> 
> But all this duplicated a lot of code from the core which is not so nice.
> 
>> @@ -678,6 +706,8 @@ static int stmfx_pinctrl_probe(struct platform_device *pdev)
>>         pctl->irq_chip.irq_set_type = stmfx_pinctrl_irq_set_type;
>>         pctl->irq_chip.irq_bus_lock = stmfx_pinctrl_irq_bus_lock;
>>         pctl->irq_chip.irq_bus_sync_unlock = stmfx_pinctrl_irq_bus_sync_unlock;
>> +       pctl->irq_chip.irq_request_resources = stmfx_gpio_irq_request_resources;
>> +       pctl->irq_chip.irq_release_resources = stmfx_gpio_irq_release_resources;
> 
> What about just adding
> 
> pctl->irq_chip.irq_enable and do stmfx_gpio_direction_input()
> in that callback instead? gpiolib will helpfully wrap it.

Thanks for pointing that out to me.

I can't use .irq_enable because of I2C transfer to set gpio direction 
(scheduling while atomic BUG occurs in this case). Indeed, .irq_enable 
is called under raw_spin_lock_irqsave in __setup_irq() while 
irq_request_resources is called before.

I could apply gpio direction in stmfx_pinctrl_irq_bus_sync_unlock 
depending on pctl->irq_gpi_src[] (checking which one is set, to set 
input direction), but this will be applied each time a consumer requests 
a stmfx gpio irq.

IMHO, keeping .irq_request/release_resources callbacks and using 
gpiochip_reqres_irq()/gpiochip_relres_irq() seems to be the best compromise.

Regards,
Amelie