Re: [v4, 5/6] mmc: kconfig: select FSL_GUTS for MMC_SDHCI_OF_ESDHC

[Scott Wood <oss@buserror.net>]

On Fri, 2016-01-08 at 06:17 +0000, Yangbo Lu wrote:
> > -----Original Message-----
> > From: Scott Wood
> > Sent: Friday, January 08, 2016 6:24 AM
> > To: Yangbo Lu; Scott Wood; Ulf Hansson
> > Cc: Lu Y.B.; linux-mmc; Xiaobo Xie; Li Leo
> > Subject: Re: [v4, 5/6] mmc: kconfig: select FSL_GUTS for
> > MMC_SDHCI_OF_ESDHC
> > 
> > On 01/06/2016 12:58 AM, Yangbo Lu wrote:
> > > > -----Original Message-----
> > > > From: Scott Wood [mailto:scottwood@freescale.com]
> > > > Sent: Tuesday, December 29, 2015 3:10 AM
> > > > To: Ulf Hansson; Yangbo Lu
> > > > Cc: Lu Yangbo-B47093; linux-mmc; Xie Xiaobo-R63061; Leo li
> > > > Subject: Re: [v4, 5/6] mmc: kconfig: select FSL_GUTS for
> > > > MMC_SDHCI_OF_ESDHC
> > > > 
> > > > On Mon, 2015-12-28 at 13:10 +0100, Ulf Hansson wrote:
> > > > > On 28 December 2015 at 11:26, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
> > > > > > > Sent: Thursday, December 17, 2015 7:31 PM
> > > > > > > To: Scott Wood
> > > > > > > Cc: Lu Yangbo-B47093; linux-mmc; Xie Xiaobo-R63061; Leo li
> > > > > > > Subject: Re: [v4, 5/6] mmc: kconfig: select FSL_GUTS for
> > > > > > > MMC_SDHCI_OF_ESDHC
> > > > > > > 
> > > > > > > [...]
> > > > > > > 
> > > > > > > > > 
> > > > > > > > > And I think stubs for reading SVR is quite a bad idea. 
> > > > > > > > >  It'll
> > > > > > > > > make the driver build but it will silently not be able to
> > > > > > > > > apply
> > > > > > > > > SVR-based
> > > > > > > workarounds.
> > > > > > > > 
> > > > > > > > It doesn't have to be "silent", the driver can return an error
> > > > > > > > (and print error messages) from its ->probe() method, if the
> > > > > > > > calls to the GUTS driver fails.
> > > > > > > > 
> > > > > > > > Anyway, I mentioned this idea only to understand the need for
> > > > > > > > *optional* GUTS supports. Perhaps there is a cross SOC drivers
> > > > > > > > that for some platforms depends on GUTS but on others it
> > > > > > > > doesn't.
> > > > > > > > 
> > > > > > > > Maybe that isn't case then!?
> > > > > > > 
> > > > > > > Can you please answer this question!?
> > > > > > > 
> > > > > > > According to the earlier versions of this patchset and from your
> > > > > > > comments [1], it *do* seems like the GUTS driver may be optional
> > > > > > > and thus stubs could address this.
> > > > > > > 
> > > > > > > Kind regards
> > > > > > > Uffe
> > > > > > > 
> > > > > > > [1]
> > > > > > > http://www.spinics.net/lists/linux-mmc/msg34412.html
> > > > > > 
> > > > > > [Lu Yangbo-B47093] Hi Scott and Uffe, In the earlier version, I'd
> > > > > > like to use syscon support and only add 'syscon' compatible in the
> > > > > > dts whose eSDHC needs to use it to get SVR.
> > > > > > But I never thought this had caused so much discussion... :(
> > > > > 
> > > > > Sorry, I understand your frustration but that's life sometimes. :-)
> > > > > 
> > > > > To me, the syscon solution is more elegant...
> > > > 
> > > > The syscon patch was terrible.  It would have accessed a certain
> > > > location in any node labelled "syscon" whether it was guts or not, in
> > > > addition to the other complaints.
> > > > 
> > > > -Scott
> > > 
> > > [Lu Yangbo-B47093] As my understand, the syscon APIs would just check
> > whether there is a 'syscon' compatible.
> > > If no, the APIs return. We still could maintain a list of compatibles
> > for guts if using syscon.
> > 
> > Where would that list of compatibles go?  Duplicated in every driver that
> > needs something from guts?  Why decentralize the implementation?
> > 
> > > In my opinion, syscon and guts driver are just two method to get SVR.
> > 
> > The guts driver could eventually handle more than just SVR, and it could
> > handle SVR better (e.g. on PPC fall back to reading the SPR if guts is
> > unavailable).
> > 
> > -Scott
> 
> [Lu Yangbo-B47093] Ok... It seems no proper place to maintain the guts list
> presently...
> I also have had a question about the guts driver.
> Could you suggest where to register the guts driver, to make it registered
> for all QorIQ platforms and avoid unavailability to call it?

In an initcall, just like other normal drivers.  Maybe subsys_initcall.

-Scott