From nobody Tue Oct 7 06:50:54 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 09E37201276; Sat, 12 Jul 2025 18:17:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752344262; cv=none; b=s7WT/Y9emjmbIUOHjugwFKkXG+mOZjzgH6plho0p4lRHNgBptIm83o658nLPmzoI45iwOMSIzQR9ksouX1kZmMkxfUoPrk4V4auyff7qr+x6YB2aCL9+by4uFkT8VcBZye5mUi/n1rX/QOdLziieeAbE0G2NChG/mfMwkqplV5Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752344262; c=relaxed/simple; bh=BE3+Mc/pI2mxEUpR5V2UrmHy317CKy34ZoYYunBC5yg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LPGquPG8wjIq84kPe7LlalGZcT+JOadkzzFtsJQ774M3AWgk9KTMvtYxeiPLujVRbXL+Q0Rzp/tLz4IUBLFD4+R413LB2bqK8lb6nNB+KZ4dFyhF0pIGwcIuUSeKFwCo23MKW732n6qfnpG67VgMOdd3hd7+HUjDpeX2tOy1Eak= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CBZjmgrQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CBZjmgrQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD028C4CEF6; Sat, 12 Jul 2025 18:17:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752344261; bh=BE3+Mc/pI2mxEUpR5V2UrmHy317CKy34ZoYYunBC5yg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CBZjmgrQZDbTi4SlTvWsSu3l7XWpLJ+oAJ3nclM3nKvGowcBQJDzFQu3lTrTTH4cm JmmwRMjeNqJobeamE/33DCRggnLprmGRHnNqlrqaelMBxZy+o/Xcr5EhEUmijYaUaQ YJwQlq0nUg6FE+pNT5L7A6xsJCBrlFZKuMTE+mZITeZzHCTp4SafkEvLJoXwSkBhcW hReZ/CCkh1NFm3ngMxX09FPQ+IfY5Gv0KALsJCnoUHnZ0wWUE7oI/9Bwal9a4WvJ9F Uw66IjjRFcLJSEkKy96UkgJE1aKo3hoOjXTL7g9me0XtKTE3Ut2HGXMoB0Met8290q PmKkY/T8srxFw== From: srini@kernel.org To: gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, "Michael C. Pratt" , INAGAKI Hiroshi , stable@vger.kernel.org, Srinivas Kandagatla Subject: [PATCH 1/2] nvmem: layouts: u-boot-env: remove crc32 endianness conversion Date: Sat, 12 Jul 2025 19:17:26 +0100 Message-ID: <20250712181729.6495-2-srini@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250712181729.6495-1-srini@kernel.org> References: <20250712181729.6495-1-srini@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Michael C. Pratt" 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 variabl= es") Reported-by: INAGAKI Hiroshi Link: https://lore.kernel.org/all/20221011024928.1807-1-musashino.open@gmai= l.com Cc: stable@vger.kernel.org # 6.12.x Cc: stable@vger.kernel.org # 6.6.x: f4cf4e5: Revert "nvmem: add new config = option" Cc: stable@vger.kernel.org # 6.6.x: 7f38b70: of: device: Export of_device_m= ake_bus_id() Cc: stable@vger.kernel.org # 6.6.x: 4a1a402: nvmem: Move of_nvmem_layout_ge= t_container() in another header Cc: stable@vger.kernel.org # 6.6.x: fc29fd8: nvmem: core: Rework layouts to= become regular devices Cc: stable@vger.kernel.org # 6.6.x: 0331c61: nvmem: core: Expose cells thro= ugh sysfs Cc: stable@vger.kernel.org # 6.6.x: 401df0d: nvmem: layouts: refactor .add_= cells() callback arguments Cc: stable@vger.kernel.org # 6.6.x: 6d0ca4a: nvmem: layouts: store owner fr= om modules with nvmem_layout_driver_register() Cc: stable@vger.kernel.org # 6.6.x: 5f15811: nvmem: layouts: add U-Boot env= layout Cc: stable@vger.kernel.org # 6.6.x Signed-off-by: Michael C. Pratt Signed-off-by: Srinivas Kandagatla --- drivers/nvmem/layouts/u-boot-env.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvmem/layouts/u-boot-env.c b/drivers/nvmem/layouts/u-b= oot-env.c index 436426d4e8f9..8571aac56295 100644 --- a/drivers/nvmem/layouts/u-boot-env.c +++ b/drivers/nvmem/layouts/u-boot-env.c @@ -92,7 +92,7 @@ int u_boot_env_parse(struct device *dev, struct nvmem_dev= ice *nvmem, 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; @@ -143,8 +143,8 @@ int u_boot_env_parse(struct device *dev, struct nvmem_d= evice *nvmem, goto err_kfree; } =20 - crc32_addr =3D (__le32 *)(buf + crc32_offset); - crc32 =3D le32_to_cpu(*crc32_addr); + crc32_addr =3D (uint32_t *)(buf + crc32_offset); + crc32 =3D *crc32_addr; crc32_data_len =3D dev_size - crc32_data_offset; data_len =3D dev_size - data_offset; =20 --=20 2.43.0 From nobody Tue Oct 7 06:50:54 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E10A228A721; Sat, 12 Jul 2025 18:17:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752344264; cv=none; b=njunf4JzioKNuzdlfyrW/Xhuxj9106kUxt63HjPG91wsSSCMWuOrwyS11UGgT+DDHvvg47YalO6W4f810lqPuFy1kQUa9Utx6g/HR58vgRdj5NfwXaemMXxDtRYWJnywnUOsPD95tYhi7LWc1Hcak0Au84MkxbXQA8GgvFI2jeA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752344264; c=relaxed/simple; bh=iz+txLZgt8thaEXgI+AQiZRzOLWLiZIRkBupCC4u23k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=B2C0tRi9ifLhxP53EoQtv+ktwmnj8uffvl1UlGbH+ZL+sdqqGf3ZYAcCyH8mp47B0zwR9QZPqVACeO81mjlDKFy6hqcz3yesHjiL+BwgwLMV1QrCoXgjyn/1b4KCMWbciRO2o69x+izV3uYNX3ITSSRzGWs+yolZHyi0bLfcONU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OJnwI31I; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OJnwI31I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4A7CC4CEF0; Sat, 12 Jul 2025 18:17:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752344263; bh=iz+txLZgt8thaEXgI+AQiZRzOLWLiZIRkBupCC4u23k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OJnwI31IMfKFYmkA4nk0PHDxxptao5byB3aasXe5Vscez2wFBNQGHO2vPnwBd3ahL +btYczBvLm4Vail33UUCmX4fofQ4kPMiTpqyvMxmtqur4DWg4VBOkRTmmkhtixm4Nq Af+/uEtgRwuLPI636IXT5rFnIQ6E6UD501iZd07GlKxfQ0NocgVCHWxxy/UpoZrNaX 51Fj87QdUXJNjV9PCItt+3S3flMl84EGGTO7d6Iph1EPTtSvGj7zAqotdPAzqm2rHX ieDxFD3UKASDoSjVHz6NRiFJWqhOKiLQNUWv5eQngJ2SIr+sbhp9g/igxZUOmJAz69 JvYW8iKStrlyQ== From: srini@kernel.org To: gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, =?UTF-8?q?Steffen=20B=C3=A4tz?= , stable@vger.kernel.org, Alexander Stein , Srinivas Kandagatla Subject: [PATCH 2/2] nvmem: imx-ocotp: fix MAC address byte length Date: Sat, 12 Jul 2025 19:17:27 +0100 Message-ID: <20250712181729.6495-3-srini@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250712181729.6495-1-srini@kernel.org> References: <20250712181729.6495-1-srini@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Steffen B=C3=A4tz The commit "13bcd440f2ff nvmem: core: verify cell's raw_len" caused an extension of the "mac-address" cell from 6 to 8 bytes due to word_size of 4 bytes. This led to a required byte swap of the full buffer length, which caused truncation of the mac-address when read. Previously, the mac-address was incorrectly truncated from 70:B3:D5:14:E9:0E to 00:00:70:B3:D5:14. Fix the issue by swapping only the first 6 bytes to correctly pass the mac-address to the upper layers. Fixes: 13bcd440f2ff ("nvmem: core: verify cell's raw_len") Cc: stable@vger.kernel.org Signed-off-by: Steffen B=C3=A4tz Tested-by: Alexander Stein Signed-off-by: Srinivas Kandagatla --- drivers/nvmem/imx-ocotp-ele.c | 5 ++++- drivers/nvmem/imx-ocotp.c | 5 ++++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/nvmem/imx-ocotp-ele.c b/drivers/nvmem/imx-ocotp-ele.c index ca6dd71d8a2e..7807ec0e2d18 100644 --- a/drivers/nvmem/imx-ocotp-ele.c +++ b/drivers/nvmem/imx-ocotp-ele.c @@ -12,6 +12,7 @@ #include #include #include +#include /* ETH_ALEN */ =20 enum fuse_type { FUSE_FSB =3D BIT(0), @@ -118,9 +119,11 @@ static int imx_ocotp_cell_pp(void *context, const char= *id, int index, int i; =20 /* Deal with some post processing of nvmem cell data */ - if (id && !strcmp(id, "mac-address")) + if (id && !strcmp(id, "mac-address")) { + bytes =3D min(bytes, ETH_ALEN); for (i =3D 0; i < bytes / 2; i++) swap(buf[i], buf[bytes - i - 1]); + } =20 return 0; } diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index 79dd4fda0329..7bf7656d4f96 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -23,6 +23,7 @@ #include #include #include +#include /* ETH_ALEN */ =20 #define IMX_OCOTP_OFFSET_B0W0 0x400 /* Offset from base address of the * OTP Bank0 Word0 @@ -227,9 +228,11 @@ static int imx_ocotp_cell_pp(void *context, const char= *id, int index, int i; =20 /* Deal with some post processing of nvmem cell data */ - if (id && !strcmp(id, "mac-address")) + if (id && !strcmp(id, "mac-address")) { + bytes =3D min(bytes, ETH_ALEN); for (i =3D 0; i < bytes / 2; i++) swap(buf[i], buf[bytes - i - 1]); + } =20 return 0; } --=20 2.43.0