[PATCH] DTS: Add compatible list for eSDHC

Scott Wood scottwood at freescale.com
Wed Jul 3 04:54:39 EST 2013


On 07/02/2013 03:00:43 AM, Zhang Haijun-B42677 wrote:
> 
> 
> 
> Regards
> Haijun.
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, July 02, 2013 8:05 AM
> > To: Zhang Haijun-B42677
> > Cc: galak at kernel.crashing.org; linuxppc-dev at lists.ozlabs.org; Zhang
> > Haijun-B42677; Fleming Andy-AFLEMING
> > Subject: Re: [PATCH] DTS: Add compatible list for eSDHC
> >
> > On 07/01/2013 12:21:50 AM, Haijun Zhang wrote:
> > > Add compatible of esdhc for below board:
> > > p2041   p3041   p4080   p5020   p5040
> > >
> > > Signed-off-by: Haijun Zhang <Haijun.Zhang at freescale.com>
> > > CC: Scott Wood <scottwood at freescale.com>
> > > CC: Fleming Andrew-AFLEMING <AFLEMING at freescale.com>
> > > ---
> > >  arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 1 +
> > > arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 1 +
> > > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 1 +
> > > arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 1 +
> > > arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 1 +
> > >  5 files changed, 5 insertions(+)
> >
> > Is there something specific that depends on this, or are you just  
> trying
> > to conform to other examples?
> >
> > I don't think we need the SoC name here, given that eSDHC has a  
> version
> > register that you can read (and an SVR in the unlikely case that  
> that
> > isn't adequate).  If you did end up relying on this device tree  
> change,
> > you'd be broken if an older device trees is used.
> >
> [Haijun Wrote:] Yes, in mmc driver (sdhci-pltfm.c)some quirks depends  
> on Soc name and its Soc version (sdhci-of-esdhc.c), even if they had  
> the same eSDHC version.

Then please use SVR for applying errata workarounds to these chips,  
rather than rely on the device tree being updated.  The SVR approach  
also lets you deal with cases where the erratum is present in one rev  
of an SoC but not another.

Is SDHCI_QUIRK_BROKEN_TIMEOUT_VAL present on these chips?  If so, which  
chips (of the same eSDHC version) is it not present on?

-Scott


More information about the Linuxppc-dev mailing list