Dear Tom,
In message 20180225134810.GU4311@bill-the-cat you wrote:
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.
Maybe I was not really clear. You are right as this is not generic file system code. Instead, it is the EXT4 support code for the environment handling.
The patch adds mmc_initialize() to env_ext4_load(), so whenever we try to load the environment from an EXT4 file system, it will initialize the MMC subsystem.
However - what if we want to load the environment from an EXT4 file system on any other storage device - say, USB, or SATA, or flash?
In all such cases the initialization of MMC would be plain wrong.
And what if we want to load the environment from any other type of file system - say, cramfs, zfs, etc. - on SDCard or eMMC? These do not initialize MMC, so it would fail?
Yes, we have the same crappy code in env/fat.c, but this is the wrong thing to do, and must be cleaned up there as well.
This is what I meant when I wrote that the file system (interface) code and the storage device support code are independent of each other, and code should be kept orthogonal - storage support like MMC etc. has no place in code dealing with a specific file system type.
I still think my NAK is reasonable.
Best regards,
Wolfgang Denk