Message-ID: <2025071656-heap-student-9163@gregkh>
Date: Wed, 16 Jul 2025 11:42:05 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Srinivas Kandagatla <srini@...nel.org>
Cc: linux-kernel@...r.kernel.org, "Michael C. Pratt" <mcpratt@...me>,
	INAGAKI Hiroshi <musashino.open@...il.com>, stable@...r.kernel.org
Subject: Re: [PATCH 1/2] nvmem: layouts: u-boot-env: remove crc32 endianness
 conversion

On Tue, Jul 15, 2025 at 04:44:00PM +0100, Srinivas Kandagatla wrote:
> 
> 
> On 7/13/25 4:42 PM, Greg KH wrote:
> > On Sun, Jul 13, 2025 at 05:41:45PM +0200, Greg KH wrote:
> >> On Sat, Jul 12, 2025 at 07:17:26PM +0100, srini@...nel.org wrote:
> >>> From: "Michael C. Pratt" <mcpratt@...me>
> >>>
> >>> 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")
> >>
> >> Note, this is a 6.1 commit id, but:
> >>
> >>> Reported-by: INAGAKI Hiroshi <musashino.open@...il.com>
> >>> Link: https://lore.kernel.org/all/20221011024928.1807-1-musashino.open@gmail.com
> >>> Cc: stable@...r.kernel.org # 6.12.x
> >>> Cc: stable@...r.kernel.org # 6.6.x: f4cf4e5: Revert "nvmem: add new config option"
> >>> Cc: stable@...r.kernel.org # 6.6.x: 7f38b70: of: device: Export of_device_make_bus_id()
> >>> Cc: stable@...r.kernel.org # 6.6.x: 4a1a402: nvmem: Move of_nvmem_layout_get_container() in another header
> >>> Cc: stable@...r.kernel.org # 6.6.x: fc29fd8: nvmem: core: Rework layouts to become regular devices
> >>> Cc: stable@...r.kernel.org # 6.6.x: 0331c61: nvmem: core: Expose cells through sysfs
> >>> Cc: stable@...r.kernel.org # 6.6.x: 401df0d: nvmem: layouts: refactor .add_cells() callback arguments
> >>> Cc: stable@...r.kernel.org # 6.6.x: 6d0ca4a: nvmem: layouts: store owner from modules with nvmem_layout_driver_register()
> >>> Cc: stable@...r.kernel.org # 6.6.x: 5f15811: nvmem: layouts: add U-Boot env layout
> >>> Cc: stable@...r.kernel.org # 6.6.x
> >>
> >> That's a load of (short) git ids for just 6.6.y?  What about 6.1.y?
> > 
> > And really, ALL of those commits are needed for this very tiny patch?
> May be not, AFAIU  Fixes: d5542923f200 ("nvmem: add driver handling
> U-Boot environment variables") should be enough.

Great, can you fix this up and resend?

thanks,

greg k-h

Powered by blists - more mailing lists