As resolved and explained in detail in commit e589d5822cac ("env: spi:
Fix gd->env_valid for the first write") and archived discussion there is
a corner case where we don't do the right thing with redundant
environments. This same exact check was present in the mmc code and
resolved with commit 813a0df27a8a ("env: Invert gd->env_valid for
env_mmc_save") and in the discussion of that patch, I noted that both
fat and ubi (and at the time, sf) were doing the same thing. Take the
time now to correct fat and ubi environment.

Signed-off-by: Tom Rini <trini@konsulko.com>

The A/B update strategy of the env's has a gap in the first 2 calls of saveenv.
The env's are stored twice on the first memory area if:
gd->env_valid == ENV_INVALID.

u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK  <-- !!!
u-boot=> saveenv
Saving Environment to MMC... Writing to redundant MMC(1)... OK
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK

This is the same issue as resolved in commit e589d5822cac ("env: spi:
Fix gd->env_valid for the first write")

Signed-off-by: Michael Glembotzki <Michael.Glembotzki@iris-sensing.com>
Signed-off-by: Jasper Orschulko <jasper@fancydomain.eu>
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
[trini: Amend the commit message]
---
Changes in v2:
- Rebase to current master
- Amend the commit message to reference the SPI version of this fix,
  which had significant follow-up discussion.

Falcon mode uses falcon_image_file from the env during mmc fs boot, but
external env can be compromised. Therefore disable access to external
env by setting SPL_ENV_IS_NOWHERE when SPL_OS_BOOT_SECURE is set.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Merge the outstanding changes from the 'next' branch to master.

%s/environemt/environment

Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>

When both SPI environment locations are invalid (gd->env_valid ==
ENV_INVALID), the first call to saveenv writes to the primary location and
sets the active flag. However, the logic for updating gd->env_valid
incorrectly sets it to ENV_REDUND, which does not match the actual location
written. This causes the first two writes to target the same location, and
alternation only begins after the second write.

Update the logic to alternate gd->env_valid based on whether the last write
was to the primary or redundant location, ensuring the first write sets
ENV_VALID and subsequent writes alternate as expected. This aligns
env_valid with the actual storage location and fixes the alternation
sequence from the first write.

With this change, the "Valid environment" printout correctly reflects the
active location after each save, and the alternation between primary and
redundant locations works as intended from the start.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Acked-by: E Shattow <e@freeshell.de>

Prepare v2025.10-rc5

Since commit 5fb88fa725 "env: Rename SYS_REDUNDAND_ENVIRONMENT to ENV_REDUNDANT"
the option SYS_REDUNDAND_ENVIRONMENT is no longer available and should be
renamed to ENV_REDUNDANT.

Fixes: 95f03ee65c0e ("env: mmc: fix offsets relative to the end of the partition")
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Prepare v2025.10-rc3

bug fix MTD_OOB_AUTO to MTD_OPS_AUTO_OOB since MTD_OOB_AUTO does not exist

Fixes: dfe64e2c8973 ("mtd: resync with Linux-3.7.1")
Signed-off-by: david regan <dregan@broadcom.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>