In v2024.10, "make envtools" is broken for at least these defconfigs:

   am335x_evm_defconfig
   rpi_3_defconfig
   rpi_4_defconfig
   mx7dsabresd_defconfig
   wandboard_defconfig
   imx8mp_evk_defconfig

The only defconfig we use for which it is not broken is
stm32mp13_defconfig. They all work just fine in v2024.07.

The symptoms are slightly different, but all related to the fact that
some transitively included header uses IS_ENABLED or CONFIG_IS_ENABLED
without linux/kconfig.h having already been included.

A simple git bisect doesn't produce anything sensible, it ends up at
3a9f642ca94 (crypto: nuvoton: npcm_sha: Support SHA 384/512) which
clearly has nothing to do with this. But digging deeper, one
eventually finds 0f92fa45603 ("env: Remove <common.h> and add needed
includes").

So at first I tried adding "#include <linux/kconfig.h>" in
include/env_default.h and include/env_flags.h. That fixes it for some,
but not all, of the above. For example rpi_3_defconfig still fails,
then in log.h complaining about BIT() and u8 not being defined. At
least BIT() is should have gotten from bitops.h, except that that's
behind ifdef __KERNEL__, so not set for the envtools build.

It turns out that the envtools source code in fw_env_private.h already
has some hackery to deal with all this, in the form of the __ASSEMBLY__
games it plays before including config.h. It seems that if we just
make sure to do that include early enough, so that config.h is indeed
parsed with that __ASSEMBLY__ hackery in place, everything builds
fine.

Fixes: 0f92fa45603 ("env: Remove <common.h> and add needed includes")
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>

Drop all duplicate newlines. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

As already done for NOR chips, if device ESIZE and ENVSECTORS static
configurations are both zero, then autodetect them at runtime.

Cc: Joe Hershberger <joe.hershberger@ni.com>
cc: Stefan Agner <stefan@agner.ch>
cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Anthony Loiseau <anthony.loiseau@allcircuits.com>

It's totally valid for read() to provide less bytes than requested
maximum. It may happen if there is no more data available yet or source
pushes data in small chunks.

This actually happens when trying to read env data from NVMEM device.
Kernel may provide NVMEM content in page size parts (like 4096 B).

This fixes warnings like:
Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 16384 bytes but got 4096
Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 12288 bytes but got 4096
Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 8192 bytes but got 4096

Since the main loop in flash_read_buf() is used to read blocks this
patch adds a new nested one.

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

Rename "addr0" and "addr1" to "buf0" and "buf1" accordingly. Name "addr"
suggests that variable contains a numeric value being some kind of
address. Name "buf" is de facto a standard name for pointer to allocated
memory for reading data to.

While at it drop redundant checks for NULL before calling free().

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

Call to fread() was changed to check for return value. The problem is it
can't be checked for returning 1 (as it is) to determine success.

We call fread() with buffer size as "size" argument. Reading any
"compatible" value shorter than buffer size will result in returning 0
even on success.

Modify code to use fstat() to determine expected read length.

This fixes regression that broke using fw_env with NVMEM devices.

Fixes: c059a22b7776 ("tools: env: fw_env: Fix unused-result warning")
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

Tell git that auto-generated C sources are now exclusively expected
under tools/generated/.

Signed-off-by: Tobias Deiminger <tdmg@linutronix.de>

Commit aeb40f1166e0 ("tools: env: use /run to store lockfile") updated the
path to the lockfile but did not update the documentation to match.

Use the new path in the documentation.

Fixes: aeb40f1166 ("tools: env: use /run to store lockfile")
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

According this issue https://github.com/ppp-project/ppp/issues/339.
Eventually, the dt-utils changed lock directory to fix missing /var/lock
directory error then make dt-utils can run normally.

We also have a similar issue with these two utilities fw_printenv and
fw_setenv will failed when the directory /var/lock is non-existent.

We have a custom linux distribution built with yocto (OpenBMC) that
use systemd and it deprecated the /var/lock directory.
More discussion in systemd/systemd#15668.

Thus, we sync with community's solution for uboot/tools/env utilities:
The current location /var/lock is considered legacy (at least by systemd).
Just use /run to store the lockfile and append the usual .lock suffix.

Tested:
Verified /run/lock is now present and fw_printenv can work in OpenBMC.

Signed-off-by: Tim Lee <timlee660101@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

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>