6.6-stable patches

added patches:
	nvmem-layouts-u-boot-env-remove-crc32-endianness-conversion.patch

diff --git a/queue-6.6/nvmem-layouts-u-boot-env-remove-crc32-endianness-conversion.patch b/queue-6.6/nvmem-layouts-u-boot-env-remove-crc32-endianness-conversion.patch
new file mode 100644 (file)
index 0000000..95f69d1
--- /dev/null
+++ b/queue-6.6/nvmem-layouts-u-boot-env-remove-crc32-endianness-conversion.patch
@@ -0,0 +1,99 @@
+From 2d7521aa26ec2dc8b877bb2d1f2611a2df49a3cf Mon Sep 17 00:00:00 2001
+From: "Michael C. Pratt" <mcpratt@pm.me>
+Date: Wed, 16 Jul 2025 15:42:10 +0100
+Subject: nvmem: layouts: u-boot-env: remove crc32 endianness conversion
+
+From: Michael C. Pratt <mcpratt@pm.me>
+
+commit 2d7521aa26ec2dc8b877bb2d1f2611a2df49a3cf upstream.
+
+On 11 Oct 2022, it was reported that the crc32 verification
+of the u-boot environment failed only on big-endian systems
+for the u-boot-env nvmem layout driver with the following error.
+
+  Invalid calculated CRC32: 0x88cd6f09 (expected: 0x096fcd88)
+
+This problem has been present since the driver was introduced,
+and before it was made into a layout driver.
+
+The suggested fix at the time was to use further endianness
+conversion macros in order to have both the stored and calculated
+crc32 values to compare always represented in the system's endianness.
+This was not accepted due to sparse warnings
+and some disagreement on how to handle the situation.
+Later on in a newer revision of the patch, it was proposed to use
+cpu_to_le32() for both values to compare instead of le32_to_cpu()
+and store the values as __le32 type to remove compilation errors.
+
+The necessity of this is based on the assumption that the use of crc32()
+requires endianness conversion because the algorithm uses little-endian,
+however, this does not prove to be the case and the issue is unrelated.
+
+Upon inspecting the current kernel code,
+there already is an existing use of le32_to_cpu() in this driver,
+which suggests there already is special handling for big-endian systems,
+however, it is big-endian systems that have the problem.
+
+This, being the only functional difference between architectures
+in the driver combined with the fact that the suggested fix
+was to use the exact same endianness conversion for the values
+brings up the possibility that it was not necessary to begin with,
+as the same endianness conversion for two values expected to be the same
+is expected to be equivalent to no conversion at all.
+
+After inspecting the u-boot environment of devices of both endianness
+and trying to remove the existing endianness conversion,
+the problem is resolved in an equivalent way as the other suggested fixes.
+
+Ultimately, it seems that u-boot is agnostic to endianness
+at least for the purpose of environment variables.
+In other words, u-boot reads and writes the stored crc32 value
+with the same endianness that the crc32 value is calculated with
+in whichever endianness a certain architecture runs on.
+
+Therefore, the u-boot-env driver does not need to convert endianness.
+Remove the usage of endianness macros in the u-boot-env driver,
+and change the type of local variables to maintain the same return type.
+
+If there is a special situation in the case of endianness,
+it would be a corner case and should be handled by a unique "compatible".
+
+Even though it is not necessary to use endianness conversion macros here,
+it may be useful to use them in the future for consistent error printing.
+
+Fixes: d5542923f200 ("nvmem: add driver handling U-Boot environment variables")
+Reported-by: INAGAKI Hiroshi <musashino.open@gmail.com>
+Link: https://lore.kernel.org/all/20221011024928.1807-1-musashino.open@gmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: "Michael C. Pratt" <mcpratt@pm.me>
+Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
+Link: https://lore.kernel.org/r/20250716144210.4804-1-srini@kernel.org
+[ applied changes to drivers/nvmem/u-boot-env.c after code was moved from drivers/nvmem/layouts/u-boot-env.c ]
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvmem/u-boot-env.c |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/nvmem/u-boot-env.c
++++ b/drivers/nvmem/u-boot-env.c
+@@ -132,7 +132,7 @@ static int u_boot_env_parse(struct u_boo
+       size_t crc32_data_offset;
+       size_t crc32_data_len;
+       size_t crc32_offset;
+-      __le32 *crc32_addr;
++      uint32_t *crc32_addr;
+       size_t data_offset;
+       size_t data_len;
+       size_t dev_size;
+@@ -183,8 +183,8 @@ static int u_boot_env_parse(struct u_boo
+               goto err_kfree;
+       }
+ 
+-      crc32_addr = (__le32 *)(buf + crc32_offset);
+-      crc32 = le32_to_cpu(*crc32_addr);
++      crc32_addr = (uint32_t *)(buf + crc32_offset);
++      crc32 = *crc32_addr;
+       crc32_data_len = dev_size - crc32_data_offset;
+       data_len = dev_size - data_offset;
+ 

diff --git a/queue-6.6/series b/queue-6.6/series
index 2d767cffab47df6b4dbdf85e9b6664e0f53ef035..a932c4124103df8d10ccb148d78820e5f70e3ea7 100644 (file)
--- a/queue-6.6/series
+++ b/queue-6.6/series
@@ -108,3 +108,4 @@ asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch
 revert-selftests-bpf-adjust-dummy_st_ops_success-to-detect-additional-error.patch
 revert-selftests-bpf-dummy_st_ops-should-reject-0-for-non-nullable-params.patch
 i2c-omap-fix-deprecated-of_property_read_bool-use.patch
+nvmem-layouts-u-boot-env-remove-crc32-endianness-conversion.patch