> -----Original Message-----
> From: Scott Wood [mailto:scottw...@freescale.com]
> Sent: Tuesday, December 29, 2015 2:48 AM
> To: Ulf Hansson
> Cc: Yangbo Lu; linux-mmc; x....@freescale.com; Leo li
> Subject: Re: [v4, 5/6] mmc: kconfig: select FSL_GUTS for
> MMC_SDHCI_OF_ESDHC
> 
> On Thu, 2015-12-17 at 12:30 +0100, Ulf Hansson wrote:
> > [...]
> >
> > > >
> > > > 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.
> 
> I'd rather it not be optional at build time for the reason I explained
> above.
>  It would be too easy for users to accidentally not enable the guts
> driver and miss the workaround.  Even if an error is printed it's easy to
> miss among all the boot spam -- and if there's any legitimate reason to
> not have the driver enabled then why would that be an "error"?  If the
> guts driver fails to bind (e.g. running in a VM, or a platform the guts
> driver doesn't recognize) that's another matter, but that should be
> handled by an error check in the guts driver, not a build-time stub.
> 
> -Scott
> 

[Lu Yangbo-B47093] For the 'optional or not optional' problem, I think Scott's 
opinion is reasonable.
If we use guts driver, 'select' could avoid missing the workaround.
If we use syscon, select is better than 'depend on' since 'depend on' needs 
user self to find out the dependency.

Anyway, we should continue the discussion to come to an agreement finally.
I would very appreciate!

Thanks.

 

Reply via email to