[PATCH V2 00/10] mmc_of_parse() adaptations, DT support for Sheevaplugs

[gmbnomis@gmail.com (Simon Baatz)]

On Tue, May 14, 2013 at 06:26:52PM +0200, Simon Baatz wrote:
> On Tue, May 14, 2013 at 08:37:47AM +0200, Guennadi Liakhovetski wrote:
> > On Mon, 13 May 2013, Simon Baatz wrote:
> > 
> > > While adding DT support for the Sheevaplugs by Globalscale Technologies
> > > (Kirkwood), it turned out that the DT binding of mvsdio lacked features to
> > > properly support the hardware (active high/low of CD and WP pins could not
> > > be described in DT).
> > > 
> > > This is standard functionality provided by the mmc_of_parse() helper
> > > function.  However, mmc_of_parse() may allocate GPIO lines.  If the
> > > allocation fails, it outputs an error, but does not return an error to its
> > > caller.  Therefore, a proposal to handle errors in mmc_of_parse() is made.
> > 
> > Thanks for the patches. In principle I'm fine either way. It is a policy 
> > decision IMHO. E.g. consider a situation. You have a DT with an SD-card 
> > slot, where card-detection is performed by a GPIO. OTOH the same pin is 
> > used on some other (optional) interface on the same board. If that other 
> > competing interface is unused, the driver isn't loaded, you can use the 
> > GPIO for card-detection. However, if that other interface is used, your 
> > attempt to get the card-detect pin will fail, but you still can use the 
> > interface in polling mode. No, I don't think this is a good example of 
> > hardware design :) User experience would depend on driver probing order, 
> > but in principle it is imaginable. So, with the current mmc_of_parse() 
> > you're more tolerant. You get a warning in the log, but the interface 
> > might still be usable. And if you're surprised why your write protection 
> > status hasn't been properly detected - just look in the log.
> 
> Yes, there is value in both ways. As should be clear by now, I prefer
> being more strict here :-).  But in the end, it is a policy decision
> as you say.

I realized that I missed one use case: There are platforms on which a
driver may load earlier than the GPIO driver.  In this case,
EPROBE_DEFER can be used to retry the probe later.  Actually, mmci.c
is an example of such a driver.

Thus, when calling of_get_named_gpio_flags() in mmc_of_parse(), we
need to check for EPROBE_DEFER and return that to the caller. I will
update the patch accordingly.

- Simon