All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	boris brezillon <b.brezillon@overkiz.com>,
	Gregory CLEMENT <gregory.clement@free-electrons.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 2/8] at91: pinctrl: don't request GPIOs used for interrupts but lock them as IRQ
Date: Mon, 24 Feb 2014 14:25:46 +0100	[thread overview]
Message-ID: <CACRpkdb8BUkLcF8=oEXsGemgFAQk6pyaX0j8t3v1xjymJsM=VQ@mail.gmail.com> (raw)
In-Reply-To: <1392199607-27452-3-git-send-email-jjhiblot@traphandler.com>

On Wed, Feb 12, 2014 at 11:06 AM, Jean-Jacques Hiblot
<jjhiblot@traphandler.com> wrote:

> During the xlate stage of the DT interrupt parsing, the at91 pinctrl driver
> requests the GPIOs that are described as interrupt sources. This prevents a
> driver to request the gpio later to get its electrical value.
> This patch replaces the gpio_request with a gpio_lock_as_irq to prevent the
> gpio to be set as an ouput while allowing a subsequent gpio_request to succeed
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>

OK, but is this really correct:

> @@ -1478,18 +1478,17 @@ static int at91_gpio_irq_domain_xlate(struct irq_domain *d,
>  {
>         struct at91_gpio_chip *at91_gpio = d->host_data;
>         int ret;
> -       int pin = at91_gpio->chip.base + intspec[0];
>
>         if (WARN_ON(intsize < 2))
>                 return -EINVAL;
>         *out_hwirq = intspec[0];
>         *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
>
> -       ret = gpio_request(pin, ctrlr->full_name);
> +       ret = gpio_lock_as_irq(&at91_gpio->chip, intspec[0]);

So when resolving an IRQ resource, we take for granted that it will be used
for IRQs and IRQs only? Is it not possible that this resolution is done
and then the driver using it unloads or whatever and it is still marked
as IRQ?

I don't think the xlate function should have such side effects on
the gpio_chip internal state. I think it should just translate.

The line is locked for IRQ the moment its startup() callback is
called, is it not?

> -       ret = gpio_direction_input(pin);
> +       ret = at91_gpio_direction_input(&at91_gpio->chip, intspec[0]);

I actually don't like this either. This kind of thing was causing
problems in the OMAP driver like hell.

I think this should be deleted from xlate and at91_gpio_direction_input()
be called from the irqchip's .startup() or even .unmask() function
instead.

Yours,
Linus Walleij

WARNING: multiple messages have this Message-ID (diff)
From: linus.walleij@linaro.org (Linus Walleij)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 2/8] at91: pinctrl: don't request GPIOs used for interrupts but lock them as IRQ
Date: Mon, 24 Feb 2014 14:25:46 +0100	[thread overview]
Message-ID: <CACRpkdb8BUkLcF8=oEXsGemgFAQk6pyaX0j8t3v1xjymJsM=VQ@mail.gmail.com> (raw)
In-Reply-To: <1392199607-27452-3-git-send-email-jjhiblot@traphandler.com>

On Wed, Feb 12, 2014 at 11:06 AM, Jean-Jacques Hiblot
<jjhiblot@traphandler.com> wrote:

> During the xlate stage of the DT interrupt parsing, the at91 pinctrl driver
> requests the GPIOs that are described as interrupt sources. This prevents a
> driver to request the gpio later to get its electrical value.
> This patch replaces the gpio_request with a gpio_lock_as_irq to prevent the
> gpio to be set as an ouput while allowing a subsequent gpio_request to succeed
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>

OK, but is this really correct:

> @@ -1478,18 +1478,17 @@ static int at91_gpio_irq_domain_xlate(struct irq_domain *d,
>  {
>         struct at91_gpio_chip *at91_gpio = d->host_data;
>         int ret;
> -       int pin = at91_gpio->chip.base + intspec[0];
>
>         if (WARN_ON(intsize < 2))
>                 return -EINVAL;
>         *out_hwirq = intspec[0];
>         *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
>
> -       ret = gpio_request(pin, ctrlr->full_name);
> +       ret = gpio_lock_as_irq(&at91_gpio->chip, intspec[0]);

So when resolving an IRQ resource, we take for granted that it will be used
for IRQs and IRQs only? Is it not possible that this resolution is done
and then the driver using it unloads or whatever and it is still marked
as IRQ?

I don't think the xlate function should have such side effects on
the gpio_chip internal state. I think it should just translate.

The line is locked for IRQ the moment its startup() callback is
called, is it not?

> -       ret = gpio_direction_input(pin);
> +       ret = at91_gpio_direction_input(&at91_gpio->chip, intspec[0]);

I actually don't like this either. This kind of thing was causing
problems in the OMAP driver like hell.

I think this should be deleted from xlate and at91_gpio_direction_input()
be called from the irqchip's .startup() or even .unmask() function
instead.

Yours,
Linus Walleij

  parent reply	other threads:[~2014-02-24 13:25 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-12 10:06 [PATCH v4 0/8] Device Tree support for the at91sam9261ek Jean-Jacques Hiblot
2014-02-12 10:06 ` Jean-Jacques Hiblot
2014-02-12 10:06 ` [PATCH v4 1/8] at91: dt: Adds support for the bus matrix declaration in the DT Jean-Jacques Hiblot
2014-02-12 10:06   ` Jean-Jacques Hiblot
2014-02-12 10:45   ` Gregory CLEMENT
2014-02-12 10:45     ` Gregory CLEMENT
2014-02-12 10:54     ` Nicolas Ferre
2014-02-12 10:54       ` Nicolas Ferre
2014-02-12 10:06 ` [PATCH v4 2/8] at91: pinctrl: don't request GPIOs used for interrupts but lock them as IRQ Jean-Jacques Hiblot
2014-02-12 10:06   ` Jean-Jacques Hiblot
2014-02-12 17:47   ` Nicolas Ferre
2014-02-12 17:47     ` Nicolas Ferre
2014-02-24 13:25   ` Linus Walleij [this message]
2014-02-24 13:25     ` Linus Walleij
2014-02-25  9:35     ` Jean-Jacques Hiblot
2014-02-25  9:35       ` Jean-Jacques Hiblot
2014-02-25  9:47       ` Jean-Jacques Hiblot
2014-02-25  9:47         ` Jean-Jacques Hiblot
2014-02-12 10:06 ` [PATCH v4 3/8] at91: dt: Add at91sam9261 dt SoC support Jean-Jacques Hiblot
2014-02-12 10:06   ` Jean-Jacques Hiblot
2014-02-12 17:28   ` Alexandre Belloni
2014-02-12 17:28     ` Alexandre Belloni
2014-02-12 19:47     ` Jean-Jacques Hiblot
2014-02-12 19:47       ` Jean-Jacques Hiblot
2014-02-13  8:10       ` Nicolas Ferre
2014-02-13  8:10         ` Nicolas Ferre
2014-02-13  8:54         ` Alexandre Belloni
2014-02-13  8:54           ` Alexandre Belloni
2014-02-12 21:04   ` Alexandre Belloni
2014-02-12 21:04     ` Alexandre Belloni
2014-02-13  6:11     ` Jean-Jacques Hiblot
2014-02-13  6:11       ` Jean-Jacques Hiblot
2014-02-12 10:06 ` [PATCH v4 4/8] at91: dt: defconfig: Added the sam9261 to the list of DT-enabled SOCs Jean-Jacques Hiblot
2014-02-12 10:06   ` Jean-Jacques Hiblot
2014-02-12 10:06 ` [PATCH v4 5/8] at91: dt: sam9261: Device Tree support for the at91sam9261ek Jean-Jacques Hiblot
2014-02-12 10:06   ` Jean-Jacques Hiblot
2014-02-12 10:06 ` [PATCH v4 6/8] at91: updated the at91_dt_defconfig with support for the ADS7846 Jean-Jacques Hiblot
2014-02-12 10:06   ` Jean-Jacques Hiblot
2014-02-12 10:06 ` [PATCH v4 7/8] ARM: at91: prepare common clk transition for sam9261 SoC Jean-Jacques Hiblot
2014-02-12 10:06   ` Jean-Jacques Hiblot
2014-02-12 10:06 ` [PATCH v4 8/8] ARM: at91: move sam9261 SoC to common clk Jean-Jacques Hiblot
2014-02-12 10:06   ` Jean-Jacques Hiblot
2014-02-12 11:14 ` [PATCH v4 0/8] Device Tree support for the at91sam9261ek Gregory CLEMENT
2014-02-12 11:14   ` Gregory CLEMENT
2014-02-12 12:34   ` Thomas Petazzoni
2014-02-12 12:34     ` Thomas Petazzoni
2014-02-12 12:36     ` Jean-Jacques Hiblot
2014-02-12 12:36       ` Jean-Jacques Hiblot
2014-02-12 12:44       ` Thomas Petazzoni
2014-02-12 12:44         ` Thomas Petazzoni
2014-02-12 13:01         ` Jean-Jacques Hiblot
2014-02-12 13:01           ` Jean-Jacques Hiblot
2014-02-12 12:35   ` Jean-Jacques Hiblot
2014-02-12 12:35     ` Jean-Jacques Hiblot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACRpkdb8BUkLcF8=oEXsGemgFAQk6pyaX0j8t3v1xjymJsM=VQ@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=b.brezillon@overkiz.com \
    --cc=gregory.clement@free-electrons.com \
    --cc=jjhiblot@traphandler.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.ferre@atmel.com \
    --cc=plagnioj@jcrosoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.