From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
Date: Thu, 30 Apr 2009 22:59:59 +0400 [thread overview]
Message-ID: <20090430185959.GA4454@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20090430175752.GA13729@ld0162-tx32.am.freescale.net>
On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > > Isn't there a more global means of doing this? I don't like having
> > > the 8536/8379 in the driver, itself.
> >
> > But that's how we prefer bindings nowadays.
>
> Block version numbers are better, if available.
>
> > > Actually, there is. Move these to the config file. But there should
> > > be a compatible property that works for all esdhc devices.
> >
> > Starting from MPC83xx/MPC85xx GPIO controllers, we try to differentiate
> > 85xx and 83xx parts. I.e. 85xx family doesn't specify 83xx family's
> > compatible entries, even if the controllers are compatible. I'm just
> > following the trend.
>
> I must have missed that memo...
>
> Why would we not recognize the compatibility if it exists?
>
> > So the current scheme is:
> > "fsl,device-<chip>", "fsl,device-<first-chip-in-a-family>;
> >
> > See this discussion:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html
>
> Bah. I don't see how it's any more "confusing to show 8610 and 8349 in
> the same dev tree" than in is to show, say, 8313 and 8349 in the same
> device tree. The concept of component A being compatible with component
> B doesn't somehow get mysterious when the systems involved have a
> different type of core.
I feel a bit dizzy.
For a year I thought that we should specify first compatible chip
in the last compatible entry, then I've been told that the first
compatible chip _in a family_ should be specified and we used
this during, say, another six months. And now you're saying that a
block version number is preferred.
Now all possible compatible naming schemes are used in various
device trees for various devices.
Can we have a guideline set in a stone that we all agree with?
In general, I follow maintainer's opinion, so I'm waiting for
Kumar's decision on that matter, and depending on the results
I'll modify the bindings and/or patches.
--
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2009-04-30 18:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-19 15:44 [U-Boot] [PATCH 0/6] eSDHC/DR USB switching on MPC837X boards Anton Vorontsov
2009-02-19 15:45 ` [U-Boot] [PATCH 1/6] fdt_support, usb: Move fdt_fixup_dr_usb() routine to drivers/usb/ Anton Vorontsov
2009-02-20 11:24 ` Jerry Van Baren
2009-02-19 15:45 ` [U-Boot] [PATCH 2/6] Add FSL "Can use" framework Anton Vorontsov
2009-02-19 19:56 ` Wolfgang Denk
2009-02-23 21:50 ` Kim Phillips
2009-02-19 15:45 ` [U-Boot] [PATCH 3/6] fsl_dr_usb: Fixup disabled USB controllers nodes in device tree Anton Vorontsov
2009-02-19 15:45 ` [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups Anton Vorontsov
2009-03-07 1:25 ` Andy Fleming
2009-04-29 21:20 ` Anton Vorontsov
2009-04-30 17:57 ` Scott Wood
2009-04-30 18:59 ` Anton Vorontsov [this message]
2009-04-30 19:28 ` Kim Phillips
2009-04-30 19:35 ` Anton Vorontsov
2009-04-30 19:39 ` Anton Vorontsov
2009-04-30 20:00 ` Kim Phillips
2009-04-30 19:59 ` Kim Phillips
2009-04-30 20:20 ` Anton Vorontsov
2009-05-01 15:59 ` Scott Wood
2009-05-01 16:49 ` Scott Wood
2009-05-02 0:32 ` Andy Fleming
2009-05-02 0:34 ` Anton Vorontsov
2009-02-19 15:45 ` [U-Boot] [PATCH 5/6] mpc83xx: MPC837XERDB: Add support for FSL eSDHC Anton Vorontsov
2009-02-19 15:45 ` [U-Boot] [PATCH 6/6] mpc83xx: MPC837XEMDS: Fixup eSDHC nodes in device tree Anton Vorontsov
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=20090430185959.GA4454@oksana.dev.rtsoft.ru \
--to=avorontsov@ru.mvista.com \
--cc=u-boot@lists.denx.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