From: "Andrew F. Davis" <afd@ti.com>
To: Rob Herring <robh@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Stephen Warren <swarren@nvidia.com>,
Andreas Fenkart <afenkart@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [RFC] Potential issue with GPIO/IRQ flags
Date: Thu, 17 Sep 2015 13:21:48 -0500 [thread overview]
Message-ID: <55FB04BC.5070605@ti.com> (raw)
In-Reply-To: <CAL_JsqKm2ttQ-rikuZYJ7=qVj+-z+Xf8PyiP16=Rh=GoBW9Zhg@mail.gmail.com>
On 09/17/2015 12:20 PM, Rob Herring wrote:
> On Thu, Sep 17, 2015 at 10:53 AM, Andrew F. Davis <afd@ti.com> wrote:
>> On 09/16/2015 08:26 PM, Rob Herring wrote:
>>>
>>> On Wed, Sep 16, 2015 at 4:07 PM, Andrew F. Davis <afd@ti.com> wrote:
>>>>
>>>> Hello all,
>>>>
>>>> I've noticed that in a few DT bindings GPIO_ACTIVE_* defines are
>>>> incorrectly used as interrupt flags. GPIO_ACTIVE_*'s are defined
>>>> in:
>>>>
>>>> include/dt-bindings/gpio/gpio.h
>>>>
>>>> and are used to describe GPIO pins. IRQ types are defined in:
>>>>
>>>> include/dt-bindings/interrupt-controller/irq.h
>>>>
>>>> and are flags for IRQ pins.
>>>
>>>
>>> It is perfectly valid for the meaning of the field to be defined by
>>> the interrupt controller, and gpio interrupts could do something
>>> different. We've tried to standardize this though.
>>>
>>
>> Sure, but in this case these are not what the interrupt controller
>> is expecting.
>
> Understood. I was talking generally, not this specific case.
>
>>>> These seem to have been mixed up in a few places, take for example:
>>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts. On line 1393 we see the
>>>> correct usage, but just before on line 1384 we see the issue.
>>>> GPIO_ACTIVE_HIGH is defined as 0, the same as IRQ_TYPE_NONE. If
>>>> this IRQ was not hard-coded with the correct edge in the driver
>>>> this would not work. What the author probably wanted was
>>>> IRQ_TYPE_LEVEL_HIGH.
>>>>
>>>> Now lets look at commit c21e678b256b, in this the IRQ flags did not
>>>> matter as the correct flag was hard-coded (IRQF_TRIGGER_LOW), this
>>>> patch moves this to the DT, but changed the flag to GPIO_ACTIVE_LOW
>>>> instead of the desired IRQ_TYPE_LEVEL_LOW. GPIO_ACTIVE_LOW is defined
>>>> as 1, or IRQ_TYPE_EDGE_RISING in IRQ flags, which is not the
>>>> equivalent to IRQF_TRIGGER_LOW the author was probably looking for.
>>>>
>>>> A quick grep (git grep "interrupt.*GPIO_ACTIVE_") shows several more
>>>> instances of this. I found this by using one of these files as an
>>>> example and giving myself a lot of problems, so I would like to fix
>>>> this before it spreads anymore.
>>>>
>>>> I have a couple of ideas of how to go at this, first would be to
>>>> just replace the incorrect flags with what was intended, but for
>>>> some of these I don't know what was intended and do not have the
>>>> board to test.
>>>>
>>>> My other solution would be to just change all instances of the GPIO
>>>> flags to their value corresponding IRQ flags:
>>>>
>>>> - interrupts = <11 GPIO_ACTIVE_LOW>;
>>>> + interrupts = <11 IRQ_TYPE_EDGE_RISING>;
>>>>
>>>> this would not make any functional change as the defines would
>>>> still evaluate to the same value, but would make it obvious where
>>>> a problem may be and that they should probably be checked and
>>>> corrected, maybe we could even put a comment after:
>>>>
>>>> - interrupts = <11 GPIO_ACTIVE_LOW>;
>>>> + interrupts = <11 IRQ_TYPE_EDGE_RISING>; // FIXME: Check IRQ type
>>>>
>>>> Well, what do you think?
>>>
>>>
>>> This seems fine. It is no less wrong.
>>>
>>
>> I'm not sure what you mean here.
>
> In this example, the correct value is probably IRQ_TYPE_LEVEL_LOW or
> IRQ_TYPE_EDGE_FALLING if the original text was correct in its
> intentions (but broken in implementation). Since the change you
> propose doesn't change the actual dtb at all, if it was wrong before
> it will still be wrong.
>
I see, that's kinda what I want, maybe for this example the intentions
are obvious but my concern is with a couple others that I don't know
what the trigger was meant to be and don't have a board to test the
changes with, so I would never be sure if I causing any regressions
with the fixes. Most of the affected boards are Tegra based (that's
why I cc'd linux-tegra), I was hoping they would be interested in
testing and finding the right values.
Andrew
> Rob
>
--
Andrew F. Davis
next prev parent reply other threads:[~2015-09-17 18:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 1:26 [RFC] Potential issue with GPIO/IRQ flags Rob Herring
[not found] ` <CAL_JsqKSfx4y_3VGhP5mR1-NJB0cJw5JLjhUk3hs92jM=usHPQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-17 15:53 ` Andrew F. Davis
[not found] ` <55FAE1FB.4070300-l0cyMroinI0@public.gmane.org>
2015-09-17 17:20 ` Rob Herring
2015-09-17 18:21 ` Andrew F. Davis [this message]
[not found] ` <55FB04BC.5070605-l0cyMroinI0@public.gmane.org>
2015-09-17 22:35 ` Stephen Warren
[not found] ` <55FB401C.7060908-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-09-17 23:49 ` Andrew F. Davis
-- strict thread matches above, loose matches on Subject: below --
2015-09-16 21:07 Andrew F. Davis
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=55FB04BC.5070605@ti.com \
--to=afd@ti.com \
--cc=afenkart@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh@kernel.org \
--cc=swarren@nvidia.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 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).