From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Shawn Guo <shawn.guo@linaro.org>,
Segher Boessenkool <segher@kernel.crashing.org>,
patches@linaro.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
devicetree-discuss@lists.ozlabs.org, linux-mmc@vger.kernel.org,
Wolfram Sang <w.sang@pengutronix.de>, Chris Ball <cjb@laptop.org>,
linux-arm-kernel@lists.infradead.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v3 4/4] mmc: sdhci-esdhc-imx: add device tree probe support
Date: Wed, 13 Jul 2011 21:32:45 +0400 [thread overview]
Message-ID: <20110713173244.GA12004@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <CACxGe6t27uvsoU6ZXYakh9ncyCeCvnqwKa5d2TQ3WUwG4xW4og@mail.gmail.com>
On Thu, Jul 14, 2011 at 01:36:39AM +0900, Grant Likely wrote:
[...]
> Only for irqs and regs. gpios have never been automatically loaded
> into resources.
Which doesn't mean we wouldn't want it sooner or later.
> > - Any pros for using named resources in the device tree? I don't
> > see any.
>
> Human readability. To know exactly what a gpio is intended to be used
> for. Particularly for the case where a device might not use all the
> gpios that it could use. Yes, the gpios property can have 'holes' in
> it, but the observation was made by several people that it is easy to
> get wrong. I for one thing the concern was well justified.
The GPIO bindings are no harder to deal with than PCI memory bindings,
not even close to that complexity. So I don't really see why you try
to simplify GPIOs, but disagree on making the same for memory and
interrupt resources.
For example arch/powerpc/boot/dts/ebony.dts, 'mcmal' node has five
interrupts (txeob, rxeob, serr, txde, rxde). Or, gianfar nodes have
either three interrupts (tx, rx, err) or just one.
The average user of 'gpios' has 1-2 entries (the noticeable exception
is USB FHCI, which has 8 GPIOs).
I.e., I don't see how GPIOs are special. I'm all for consistency,
that's it. If that doesn't work for IRQs, then I want to understand
why so. And if you explain why named resources are no good for IRQs,
maybe I could use the same argument against named GPIOs? :-)
Or it could be otherwise: we agree that named resources are good, and
we should explicitly write when to use named and when to use anonymous
resources.
> > So, I suggest to at least discuss this stuff a little bit more
> > before polluting device trees with dubious ideas.
>
> It was discussed on list quite a while ago.
I probably wasn't Cc'ed, can you point me to that thread?
The last time I was Cc'ed on a such discussion, we (well who cared
enough to 'vote') agreed* that we should wait with deploying named
GPIOs scheme, and discuss it later. And here we are.
The patch that added of_get_named_gpio() triggered no discussion
at all, but I wasn't Cc'ed either.
* http://lists.ozlabs.org/pipermail/linuxppc-dev/2008-October/064701.html
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
WARNING: multiple messages have this Message-ID (diff)
From: cbouatmailru@gmail.com (Anton Vorontsov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 4/4] mmc: sdhci-esdhc-imx: add device tree probe support
Date: Wed, 13 Jul 2011 21:32:45 +0400 [thread overview]
Message-ID: <20110713173244.GA12004@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <CACxGe6t27uvsoU6ZXYakh9ncyCeCvnqwKa5d2TQ3WUwG4xW4og@mail.gmail.com>
On Thu, Jul 14, 2011 at 01:36:39AM +0900, Grant Likely wrote:
[...]
> Only for irqs and regs. gpios have never been automatically loaded
> into resources.
Which doesn't mean we wouldn't want it sooner or later.
> > - Any pros for using named resources in the device tree? I don't
> > ?see any.
>
> Human readability. To know exactly what a gpio is intended to be used
> for. Particularly for the case where a device might not use all the
> gpios that it could use. Yes, the gpios property can have 'holes' in
> it, but the observation was made by several people that it is easy to
> get wrong. I for one thing the concern was well justified.
The GPIO bindings are no harder to deal with than PCI memory bindings,
not even close to that complexity. So I don't really see why you try
to simplify GPIOs, but disagree on making the same for memory and
interrupt resources.
For example arch/powerpc/boot/dts/ebony.dts, 'mcmal' node has five
interrupts (txeob, rxeob, serr, txde, rxde). Or, gianfar nodes have
either three interrupts (tx, rx, err) or just one.
The average user of 'gpios' has 1-2 entries (the noticeable exception
is USB FHCI, which has 8 GPIOs).
I.e., I don't see how GPIOs are special. I'm all for consistency,
that's it. If that doesn't work for IRQs, then I want to understand
why so. And if you explain why named resources are no good for IRQs,
maybe I could use the same argument against named GPIOs? :-)
Or it could be otherwise: we agree that named resources are good, and
we should explicitly write when to use named and when to use anonymous
resources.
> > So, I suggest to at least discuss this stuff a little bit more
> > before polluting device trees with dubious ideas.
>
> It was discussed on list quite a while ago.
I probably wasn't Cc'ed, can you point me to that thread?
The last time I was Cc'ed on a such discussion, we (well who cared
enough to 'vote') agreed* that we should wait with deploying named
GPIOs scheme, and discuss it later. And here we are.
The patch that added of_get_named_gpio() triggered no discussion
at all, but I wasn't Cc'ed either.
* http://lists.ozlabs.org/pipermail/linuxppc-dev/2008-October/064701.html
--
Anton Vorontsov
Email: cbouatmailru at gmail.com
next prev parent reply other threads:[~2011-07-13 17:32 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-06 16:47 [PATCH v3 0/4] Add device tree probe for sdhci-esdhc-imx Shawn Guo
2011-07-06 16:47 ` Shawn Guo
2011-07-06 16:47 ` [PATCH v3 1/4] mmc: sdhci-esdhc-imx: do not reference platform data after probe Shawn Guo
2011-07-06 16:47 ` Shawn Guo
2011-07-06 21:03 ` Grant Likely
2011-07-06 21:03 ` Grant Likely
2011-07-06 16:47 ` [PATCH v3 2/4] mmc: sdhci-esdhc-imx: get rid of the uses of cpu_is_mx() Shawn Guo
2011-07-06 16:47 ` Shawn Guo
2011-07-06 16:47 ` [PATCH v3 3/4] mmc: sdhci-pltfm: dt device does not pass parent to sdhci_alloc_host Shawn Guo
2011-07-06 16:47 ` Shawn Guo
2011-07-06 16:47 ` [PATCH v3 4/4] mmc: sdhci-esdhc-imx: add device tree probe support Shawn Guo
2011-07-06 16:47 ` Shawn Guo
2011-07-06 21:05 ` Grant Likely
2011-07-06 21:05 ` Grant Likely
2011-07-13 15:52 ` Anton Vorontsov
2011-07-13 15:52 ` Anton Vorontsov
2011-07-13 16:09 ` Scott Wood
2011-07-13 16:09 ` Scott Wood
2011-07-13 16:28 ` Anton Vorontsov
2011-07-13 16:28 ` Anton Vorontsov
2011-07-13 16:36 ` Grant Likely
2011-07-13 16:36 ` Grant Likely
2011-07-13 17:32 ` Anton Vorontsov [this message]
2011-07-13 17:32 ` Anton Vorontsov
2011-07-09 22:14 ` [PATCH v3 0/4] Add device tree probe for sdhci-esdhc-imx Chris Ball
2011-07-09 22:14 ` Chris Ball
2011-07-10 1:37 ` Shawn Guo
2011-07-10 1:37 ` Shawn Guo
2011-07-19 1:51 ` Chris Ball
2011-07-19 1:51 ` Chris Ball
2011-07-19 8:10 ` Sascha Hauer
2011-07-19 8:10 ` Sascha Hauer
2011-07-19 8:59 ` Shawn Guo
2011-07-19 8:59 ` Shawn Guo
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=20110713173244.GA12004@oksana.dev.rtsoft.ru \
--to=cbouatmailru@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=cjb@laptop.org \
--cc=david@gibson.dropbear.id.au \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=patches@linaro.org \
--cc=segher@kernel.crashing.org \
--cc=shawn.guo@linaro.org \
--cc=w.sang@pengutronix.de \
/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.