All of lore.kernel.org
 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 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.