From: computersforpeace@gmail.com (Brian Norris)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/6] dt-bindings: brcmstb-gpio: document properties for wakeup
Date: Fri, 29 May 2015 18:37:09 -0700 [thread overview]
Message-ID: <20150530013709.GY27753@ld-irv-0074> (raw)
In-Reply-To: <CADtm3G43-EBUOwAxcT2B-0syzDtpjdyfPmOHmmDsNN8+FgoZAA@mail.gmail.com>
On Fri, May 29, 2015 at 05:57:50PM -0700, Gregory Fong wrote:
> On Fri, May 29, 2015 at 5:36 PM, Brian Norris
> <computersforpeace@gmail.com> wrote:
> > On Thu, May 28, 2015 at 07:14:07PM -0700, Gregory Fong wrote:
> >> --- a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
> >> +++ b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
> >> @@ -33,6 +33,12 @@ Optional properties:
...
> >> - #interrupt-cells:
> >> Should be <2>. The first cell is the GPIO number, the second should specify
> >> flags. The following subset of flags is supported:
> >> @@ -48,7 +54,10 @@ Optional properties:
> >> Marks the device node as an interrupt controller
> >>
> >> - interrupt-names:
> >> - The name of the IRQ resource used by this controller
> >> + The names of the IRQ resources used by this controller
> >
> > If you're specifying names, you should list them here.
>
> I was wondering about that. Some bindings have them listed, some
> don't. In this case I know what names currently exist but there could
> certainly be different ones in the future. How does that work? Or am
> I misunderstanding what this field is used for? Where are the
> documented rules for this?
The only documentation I see is:
Documentation/devicetree/bindings/resource-names.txt
That documents the basics of the *-names properties, not their expected
usage.
In practice, they're only useful if you have enough optional resources
that fixed indexing isn't sufficient, and you need to use
platform_get_resource_byname().
So IMO, their purposes seems to be one of these:
(1) functional (e.g., for get_resource_byname(), when you have more than
one optional resource)
(2) self-documentation (which might run counter to #1, as you begin
generating too many unique names)
(3) no purpose
So IMO, if you ever want (1), they shouldn't have instance-specific
naming, but should use something generic to the device class. Otherwise,
they are just self-documentation, and aren't functionally useful. So
IMO, these sorts of names:
interrupt-names = "upg_gio_aon", "upg_gio_aon_wakeup";
work better as functional descriptions:
interrupt-names = "gio", "wakeup";
But in the end, I wouldn't foresee you needing to do (1), so you're left
with (2) or (3), at which point I'm not sure if you should even mention
the property.
Just my 2 cents (and those cents may not even be worth face value),
Brian
next prev parent reply other threads:[~2015-05-30 1:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-29 2:14 [PATCH v2 0/6] GPIO support for BRCMSTB Gregory Fong
2015-05-29 2:14 ` [PATCH v2 1/6] gpio: Add GPIO support for Broadcom STB SoCs Gregory Fong
2015-06-02 13:40 ` Linus Walleij
2015-05-29 2:14 ` [PATCH v2 2/6] gpio: brcmstb: Add interrupt support Gregory Fong
2015-05-30 0:10 ` Brian Norris
2015-05-30 1:30 ` Gregory Fong
2015-06-02 13:33 ` Linus Walleij
2015-05-29 2:14 ` [PATCH v2 3/6] dt-bindings: brcmstb-gpio: document properties for wakeup Gregory Fong
2015-05-30 0:36 ` Brian Norris
2015-05-30 0:57 ` Gregory Fong
2015-05-30 1:37 ` Brian Norris [this message]
2015-05-30 1:51 ` Gregory Fong
2015-05-29 2:14 ` [PATCH v2 4/6] gpio: brcmstb: Allow GPIOs to be wakeup sources Gregory Fong
2015-05-30 0:43 ` Brian Norris
2015-06-02 17:27 ` Gregory Fong
2015-06-02 13:45 ` Linus Walleij
2015-06-02 17:27 ` Gregory Fong
2015-05-29 2:14 ` [PATCH v2 5/6] ARM: brcmstb: Select ARCH_WANT_OPTIONAL_GPIOLIB Gregory Fong
2015-05-29 21:53 ` Florian Fainelli
2015-06-02 13:42 ` Linus Walleij
2015-05-29 2:14 ` [PATCH v2 6/6] ARM: brcmstb: Add default gpio number Gregory Fong
2015-05-29 21:54 ` Florian Fainelli
2015-06-02 13:41 ` Linus Walleij
2015-05-29 16:26 ` [PATCH v2 0/6] GPIO support for BRCMSTB Florian Fainelli
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=20150530013709.GY27753@ld-irv-0074 \
--to=computersforpeace@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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