[U-Boot] Inconsistencies in commands regarding load_addr

[Stephen Warren <swarren@wwwdotorg.org>]

On 10/07/2015 10:40 PM, Wolfgang Denk wrote:
> Dear Beno?t,
>
> In message <5613E20F.8060306@wsystem.com> you wrote:
>>
>> I've just noticed that before the commit
>> 045fa1e1142552799ad3203e9e0bc22a11e866ea, ext2load and ext4load were setting the
>> load_addr global variable, but not fatload. Since then, none of these commands
>> set load_addr (initially derived from the loadaddr environment variable).
>
> That's bad.
>
>> ubifsload also does not set load_addr, but a quick grep shows that some other
>> filesystem commands set it, e.g. for zfs, jffs2, reiser or cramfs.
>>
>> Also, some commands set it only on success, while some other commands set it
>> from the command line arguments unconditionally.
>>
>> What's the expected correct behavior here?
>
> After successful loading the data to memory, load_addr should be set
> correctly, for all commands.  In the error case, the value of
> load_addr is undefined.

Is this documented anywhere? If not, I'm not convinced that there's a 
contract to be followed; it "just happens" that some filesystem-related 
commands work(ed) that way (and as Beno?t pointed out, apparently some 
don't irrespective of the mentioned patch).