Fix unused-result warning about fread.

tools/env/fw_env.c: In function ‘find_nvmem_device’:
tools/env/fw_env.c:1751:3: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
 1751 |   fread(buf, sizeof(buf), 1, fp);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

The function calls opendir() but missing the corresponding
closedir() before exit the function.
Add missing closedir() to fix it.

Signed-off-by: Miaoqian Lin <linmq006@gmail.com>

A new DT binding for describing environment data block has been added in
Linux's commit 5db1c2dbc04c ("dt-bindings: nvmem: add U-Boot environment
variables binding"). Once we get a proper Linux NVMEM driver it'll be
possible to use Linux's binary interface for user-space as documented
in the:
https://www.kernel.org/doc/html/latest/driver-api/nvmem.html

This commits makes fw_env fallback to looking for a compatible NVMEM
device in case config file isn't present. In a long term this may make
config files redundant and avoid code (info) duplication.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

Environment variables can be stored in two formats:
1. Single entry with header containing CRC32
2. Two entries with extra flags field in each entry header

For that reason fw_env_open() has two main code paths and there are
pointers for CRC32/flags/data.

Previous implementation was a bit hard to follow:
1. It was checking for used format twice (in reversed order each time)
2. It was setting "environment" global struct fields to some temporary
   values that required extra comments explaining it

This change simplifies that code:
1. It introduces two clear code paths
2. It sets "environment" global struct fields values only once it really
   knows them

To be fair there are *two* crc32() calls now and an extra pointer
variable but that should be cheap enough and worth it.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

It's usually easier to understand code & follow it if all arguments are
passed explicitly. Many coding styles also discourage using global
variables.

Behaviour of flash_io() was a bit unintuitive as it was writing to a
buffer referenced in a global struct. That required developers to
remember how it works and sometimes required hacking "environment"
global struct variable to read data into a proper buffer.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

Commit "fw_setenv: lock the flash only if it was locked before"
checks for Locked status with uninitialized erase data.
Address by moving the test for MEMISLOCKED.

Fixes: 8a726b852502 ("fw_setenv: lock the flash only if it was locked before")
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>

On some cases, the actual number of bytes read can be shorter
than what was requested. This can be handled gracefully by
taking this difference into account instead of exiting.

Signed-off-by: Thibault Ferrante <thibault.ferrante@gmail.com>

The UBI_IOCVOLUP ioctl can fail if exclusive access to the volume isn't
obtained. If this happens, the flush operation doesn't return error,
leaving the caller without knowledge of missing flush.

Fix this by forwarding the error (-1) from ubi_update_start().

Fixes: 34255b92e6e ("tools: env: Add support for direct read/write UBI volumes")
Signed-off-by: Martin Hundebøll <martin@geanix.com>

Set this variable to 0 to avoid a warning about an unused variable. This
happens on gcc 7.5.0 for me.

Signed-off-by: Simon Glass <sjg@chromium.org>

The printf() string produces a warning about %d not matching size_t. Fix
it and put the format string on one line to avoid a checkpatch warning.

Signed-off-by: Simon Glass <sjg@chromium.org>