[PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Lu Y.B.]

> > > > > For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
> > > > > version value and sdhc spec version value. This will break down
> > > > > the ADMA data transfer. So add workaround to get right value
> > > > > VVN=0x13, SVN = 0x1.
> > > >
> > > > So T4240-R1.0-R2.0 is the version of the controller, right?
> > > >
> > > > If I understand correct you are checking what CPU/SoC you are
> > > > running on, to figure out which controller version you are using,
> > > > as that can't be fetched (trusted) from the registers of the esdhc
> > > > controller itself!?
> > > >
> > > > Instead, you could deal with this directly in the DTS files. I
> > > > assume you have some DTS file for each SoC/board variant, right?
> > >
> > > No, we do not have a separate DTS file for each revision of an SoC
> > > -- and if we did, we'd constantly have people using the wrong one.
> > >
> > > > In principle, in your DTS file specific for the board/SoC that
> > > > holds the T4240-R1.0-R2.0 version of the controller, should add a
> > > > specific esdhc DT property to indicate this errata.
> > >
> > > No, because (in addition to the above issue about chip revisions)
> > > the device tree is stable ABI and errata are often discovered after
> > > device trees are deployed.
> >
> > Fair enough. Then what is your suggestion for the solution here?
> 
> As I said in my comment on patch 2/3, read SVR from the device-
> config/guts MMIO block, which works on both PPC and ARM.
> 
> -Scott

Thanks, Scott.
I checked the device nodes of device-config/guts, finding all the platforms has not a uniform compatible name.
Could I add a compatible name called "fsl, dcfg"("fsl, guts" if using guts) for PowerPC P series, T series, B series boards, so that I could get this device node by compatible without knowing platform? 

Or Do you know there is another method to get this device node in code easily without knowing platform?

Best regards,
Yangbo Lu