[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Anton Vorontsov <avorontsov@ru.mvista.com>]

On Thu, Apr 30, 2009 at 02:28:52PM -0500, Kim Phillips wrote:
> On Thu, 30 Apr 2009 22:59:59 +0400
> Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> 
> > 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.
> 
> I, for one, have disagreed with the superfluous <CHIP> prefix for quite
> some time now - see the SEC node description and/or
> http://ozlabs.org/pipermail/linuxppc-dev/2008-July/058867.html.
> 
> fyi block version number is available for the eSDHC block.  It's
> version is at v0.9 for the 8379, 1.0 for the mpc8536rev1, and 1.0.1 for
> the mpc8536rev1.1.  I'm not familiar with it enough to know whether the
> 3rd degree of precision is needed though.

What if there is some errata in 8377 chip (with 1.0 revision), and
not in 8378 chip (also 1.0 revision)?

IMO <chip> prefix is more specific than a block revision.

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2