public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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