From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Shawn Guo <shawn.guo@linaro.org>,
patches@linaro.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,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
David Gibson <david@gibson.dropbear.id.au>,
Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: [PATCH v3 4/4] mmc: sdhci-esdhc-imx: add device tree probe support
Date: Wed, 13 Jul 2011 19:52:12 +0400 [thread overview]
Message-ID: <20110713155212.GB7875@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20110706210518.GD5371@ponder.secretlab.ca>
Hi,
On Wed, Jul 06, 2011 at 03:05:18PM -0600, Grant Likely wrote:
> On Thu, Jul 07, 2011 at 12:47:50AM +0800, Shawn Guo wrote:
> > The patch adds device tree probe support for sdhci-esdhc-imx driver.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Wolfram Sang <w.sang@pengutronix.de>
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
[...]
> > +Optional properties:
> > +- fsl,card-wired : Indicate the card is wired to host permanently
> > +- fsl,cd-internal : Indicate to use controller internal card detection
> > +- fsl,wp-internal : Indicate to use controller internal write protection
> > +- cd-gpios : Specify GPIOs for card detection
> > +- wp-gpios : Specify GPIOs for write protection
[...]
> > + cd-gpios = <&gpio0 6 0>; /* GPIO1_6 */
> > + wp-gpios = <&gpio0 5 0>; /* GPIO1_5 */
Is there any particular reason why we started using named GPIOs
in the device tree? To me, that's quite drastic change... should
we start using named regs and interrupts as well? Personally, I
don't think that the idea is great, as now you don't know where
to expect memory resources, interrupt resources and, eventually
GPIO resources.
Just a few disadvantages off the top of my head:
- You can't statically validate your device tree for correctness.
Today dtc checks #{address,size}-cells sanity for 'regs' and
'ranges';
- You can't automatically convert named resources into 'struct
resource *', as we do for platform devices now;
- Any pros for using named resources in the device tree? I don't
see any.
So, I suggest to at least discuss this stuff a little bit more
before polluting device trees with dubious ideas.
p.s.
As for this particular patch, I really don't see why we should
use named GPIOs. For consistency, I'd suggest to reuse bindings
from Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt.
Plus, fsl,cd-internal and fsl,wp-internal is not needed: either
you specify GPIOs or not. That already signals whether driver
should use internal detection (i.e. 'present' register) or
external (i.e. GPIO).
And also, why {cd,wp}-gpioS (plural)?
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
next prev parent reply other threads:[~2011-07-13 15:52 UTC|newest]
Thread overview: 17+ 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 ` [PATCH v3 1/4] mmc: sdhci-esdhc-imx: do not reference platform data after probe Shawn Guo
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 ` [PATCH v3 3/4] mmc: sdhci-pltfm: dt device does not pass parent to sdhci_alloc_host 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 21:05 ` Grant Likely
2011-07-13 15:52 ` Anton Vorontsov [this message]
2011-07-13 16:09 ` Scott Wood
2011-07-13 16:28 ` Anton Vorontsov
2011-07-13 16:36 ` Grant Likely
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-10 1:37 ` Shawn Guo
2011-07-19 1:51 ` Chris Ball
2011-07-19 8:10 ` Sascha Hauer
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=20110713155212.GB7875@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 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).