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

[Lukasz Majewski <lukma@denx.de>]

Hi Tom, Wolfgang,

> On Sun, Feb 25, 2018 at 09:53:10AM +0100, Wolfgang Denk wrote:
> > Dear Tom Rini,
> > 
> > In message <20180224215325.GQ4311@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)?

As I've read the discussion between Tom and Wolfgang - I'm wondering if
this initialization could be done in the driver model? 

I think that DM is a right place to put such code (ecluding the case
of env in eMMC readed in SPL).

I've added Simon to CC, so maybe he can give us some insights.

> Thanks!
> 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180225/31133e6c/attachment.sig>