From: Linus Walleij <linus.walleij@linaro.org>
To: Alexandre TORGUE <alexandre.torgue@st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Patrice Chotard <patrice.chotard@st.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Rob Herring <robh+dt@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/4] pinctrl: stm32: set pin to gpio input when used as interrupt
Date: Mon, 24 Apr 2017 14:36:27 +0200 [thread overview]
Message-ID: <CACRpkdYZixkJroS-gQxYL6xW47-J9UiNv4hOO9F-1b2eYLr8XQ@mail.gmail.com> (raw)
In-Reply-To: <1491577811-26989-2-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> This patch ensures that pin is correctly set as gpio input when it is used
> as an interrupt.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
(...)
> +static int stm32_gpio_irq_request_resources(struct irq_data *irq_data)
> +{
> + struct stm32_gpio_bank *bank = irq_data->domain->host_data;
> + u32 ret;
> +
> + if (!gpiochip_is_requested(&bank->gpio_chip, irq_data->hwirq)) {
> + ret = stm32_gpio_request(&bank->gpio_chip, irq_data->hwirq);
> + if (ret)
> + return ret;
> + }
This is wrong. You should only use gpiochip_lock_as_irq(), because of the
following in Documentation/gpio/driver.txt:
---------------
It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
irq_chip are orthogonal, and offering their services independent of each
other.
(...)
So always prepare the hardware and make it ready for action in respective
callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
been called first.
This orthogonality leads to ambiguities that we need to solve: if there is
competition inside the subsystem which side is using the resource (a certain
GPIO line and register for example) it needs to deny certain operations and
keep track of usage inside of the gpiolib subsystem. This is why the API
below exists.
Locking IRQ usage
-----------------
Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
to mark the GPIO as being used as an IRQ:
int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
is released:
void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
When implementing an irqchip inside a GPIO driver, these two functions should
typically be called in the .startup() and .shutdown() callbacks from the
irqchip.
When using the gpiolib irqchip helpers, these callback are automatically
assigned.
--------------
It is because of easy to make errors like this that I prefer that people try
to use GPIOLIB_IRQCHIP helpers insteaf of rolling their own irqchip code.
Yours,
Linus Walleij
next prev parent reply other threads:[~2017-04-24 12:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 15:10 [PATCH 0/4] Add fixes to STM32 pintrl Alexandre TORGUE
[not found] ` <1491577811-26989-1-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
2017-04-07 15:10 ` [PATCH 1/4] pinctrl: stm32: set pin to gpio input when used as interrupt Alexandre TORGUE
2017-04-24 12:36 ` Linus Walleij [this message]
2017-04-24 16:40 ` Alexandre Torgue
2017-04-07 15:10 ` [PATCH 3/4] pinctrl: stm32: Implement .get_direction gpio_chip callback Alexandre TORGUE
2017-04-24 12:37 ` Linus Walleij
2017-04-24 16:07 ` Alexandre Torgue
2017-04-07 15:10 ` [PATCH 2/4] pinctrl: stm32: replace device_initcall() with arch_initcall() Alexandre TORGUE
2017-04-24 12:22 ` Linus Walleij
2017-04-07 15:10 ` [PATCH 4/4] ARM: dts: stm32: Set gpio controller also as interrupt controller Alexandre TORGUE
[not found] ` <1491577811-26989-5-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
2017-04-24 12:38 ` Linus Walleij
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=CACRpkdYZixkJroS-gQxYL6xW47-J9UiNv4hOO9F-1b2eYLr8XQ@mail.gmail.com \
--to=linus.walleij@linaro.org \
--cc=alexandre.torgue@st.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=patrice.chotard@st.com \
--cc=paul.gortmaker@windriver.com \
--cc=robh+dt@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).