[U-Boot] [PATCH v2 1/2] mmc: Board-specific MMC power initializations

[Tom Rini]

On Wed, Nov 05, 2014 at 06:35:20PM +0100, Paul Kocialkowski wrote:
> Hi there, thanks for the review,
> 
> Le mardi 04 novembre 2014 à 13:32 -0500, Tom Rini a écrit :
> > On Tue, Nov 04, 2014 at 07:58:38PM +0200, Igor Grinberg wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > Hi Tom,
> > > 
> > > On 11/04/14 17:56, Tom Rini wrote:
> > > > On Sat, Nov 01, 2014 at 11:35:43AM +0100, Paul Kocialkowski wrote:
> > > > 
> > > >> Some devices may use non-standard combinations of regulators to power MMC:
> > > >> this allows these devices to provide a board-specific MMC power init function
> > > >> to set everything up in their own way.
> > > >>
> > > >> Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
> > > >> ---
> > > >>  drivers/mmc/mmc.c | 8 ++++++++
> > > >>  include/mmc.h     | 2 ++
> > > >>  2 files changed, 10 insertions(+)
> > > >>
> > > >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > > >> index 44a4feb..125f347 100644
> > > >> --- a/drivers/mmc/mmc.c
> > > >> +++ b/drivers/mmc/mmc.c
> > > >> @@ -1277,6 +1277,12 @@ block_dev_desc_t *mmc_get_dev(int dev)
> > > >>  }
> > > >>  #endif
> > > >>  
> > > >> +/* board-specific MMC power initializations. */
> > > >> +__weak int board_mmc_power_init(void)
> > > >> +{
> > > >> +	return -1;
> > > >> +}
> > > > 
> > > > Since we don't check error return here which I think is fine just make
> > > > this a void?  Thanks!
> > > 
> > > There is v3 posted a while ago...
> > > We have also agreed on v4..
> 
> Note that v3 and v4 are the same, except that v3 didn't apply on top of
> master.
> 
> > Yeah, oops, didn't delete these after catch-up.  I'm still not sure we
> > should continue adding more unchecked return values "just because".
> 
> I agree that we shouldn't have an unchecked return value. So we could
> either check the return value and print a warning, without aborting the
> init sequence (what Igor proposed initially) or just make this return
> void (what you both seem to agree on).
> 
> I'm fine with both solutions. I guess that enabling a regulator could
> fail (say, because of an i2c error), so there is still sense in
> returning int.
> 
> Let me know of what your definitive answer on this is. I'll make a new
> patchset probably this friday (I'm running on a very tight schedule
> until then).

Lets go with void.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141105/c01d9351/attachment.pgp>