[U-Boot] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it

[Tom Rini]

On Sun, Feb 25, 2018 at 09:53:10AM +0100, Wolfgang Denk wrote:
> Dear Tom Rini,
> 
> In message <20180224215325.GQ4311 at bill-the-cat> you wrote:
> > 
> > > Why do you ignore this NAK, and why do you add this patch so late in
> > > the release cycle anyway?
> > 
> > Sorry, didn't v2 address your concerns?  We don't initialize the device
> > because maybe we'll have env there, we initalize mmc because we need to
> > check that it is there.  Thanks!
> 
> No, it does not.  As is, we initialize MMC in the EXT4 code (in
> env_ext4_load()). If we go that route, we would have to add similar
> init calls to all other file systemn load routines as well.
> 
> This does not make sense to me.  This pollutes the code with
> unrelated things - file system code should not depend on any
> underlaying driver suport.  It increases code size, makes the code
> harder to maintain (if you need to change this, there is good
> chances to forget the same change in other file systems), and there
> is a good chance that in the end you will initialzie MMC even if you
> don't use it.
> 
> We should keep the code clean and orthogonal.  Driver init code has
> no place in file system code.
> 
> If needed, the drivers have to make sure to auto--initialize on
> first access.
> 
> I hold my NAK on this patch.  It is the wrong thing to do.

I think you have this a little bit wrong.  But, it's also where we are
with the DM conversion.  This _is_ the first place we're trying to
access the MMC.  And it's not in the filesystem code, it's in the
environment code.

That said, Faiz, what exactly is the failure sequence (and hardware)?
Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180225/83cb01de/attachment.sig>