Since commit 55d4980ce55b ("nvmem: core: support specifying both: cell raw data & post read lengths"), the aligned length (e.g. '8' instead of '6') is passed to the read_post_process callback. This causes that the 2 bytes following the MAC address in the ocotp are swapped to the beginning of the address. As a result, an invalid MAC address is returned and to make it even worse, this address can be equal on boards with the same OUI vendor prefix.
Fixes: 55d4980ce55b ("nvmem: core: support specifying both: cell raw data & post read lengths") Signed-off-by: Christian Eggers ceggers@arri.de Cc: stable@vger.kernel.org --- Tested on i.MX6ULL, but I assume that this is also required for. imx-ocotp-ele.c (i.MX93).
drivers/nvmem/imx-ocotp-ele.c | 5 +++-- drivers/nvmem/imx-ocotp.c | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/nvmem/imx-ocotp-ele.c b/drivers/nvmem/imx-ocotp-ele.c index 83617665c8d7..07830785ebf1 100644 --- a/drivers/nvmem/imx-ocotp-ele.c +++ b/drivers/nvmem/imx-ocotp-ele.c @@ -6,6 +6,7 @@ */
#include <linux/device.h> +#include <linux/if_ether.h> #include <linux/io.h> #include <linux/module.h> #include <linux/nvmem-provider.h> @@ -119,8 +120,8 @@ static int imx_ocotp_cell_pp(void *context, const char *id, int index,
/* Deal with some post processing of nvmem cell data */ if (id && !strcmp(id, "mac-address")) - for (i = 0; i < bytes / 2; i++) - swap(buf[i], buf[bytes - i - 1]); + for (i = 0; i < ETH_ALEN / 2; i++) + swap(buf[i], buf[ETH_ALEN - i - 1]);
return 0; } diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index 22cc77908018..4dd3b0f94de2 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -16,6 +16,7 @@
#include <linux/clk.h> #include <linux/device.h> +#include <linux/if_ether.h> #include <linux/io.h> #include <linux/module.h> #include <linux/nvmem-provider.h> @@ -228,8 +229,8 @@ static int imx_ocotp_cell_pp(void *context, const char *id, int index,
/* Deal with some post processing of nvmem cell data */ if (id && !strcmp(id, "mac-address")) - for (i = 0; i < bytes / 2; i++) - swap(buf[i], buf[bytes - i - 1]); + for (i = 0; i < ETH_ALEN / 2; i++) + swap(buf[i], buf[ETH_ALEN - i - 1]);
return 0; }
Hi Christian,
On Fri, Jul 11, 2025 at 9:01 AM Christian Eggers ceggers@arri.de wrote:
Since commit 55d4980ce55b ("nvmem: core: support specifying both: cell raw data & post read lengths"), the aligned length (e.g. '8' instead of '6') is passed to the read_post_process callback. This causes that the 2 bytes following the MAC address in the ocotp are swapped to the beginning of the address. As a result, an invalid MAC address is returned and to make it even worse, this address can be equal on boards with the same OUI vendor prefix.
Fixes: 55d4980ce55b ("nvmem: core: support specifying both: cell raw data & post read lengths") Signed-off-by: Christian Eggers ceggers@arri.de Cc: stable@vger.kernel.org
Tested on i.MX6ULL, but I assume that this is also required for. imx-ocotp-ele.c (i.MX93).
Steffen has recently sent a similar fix:
https://lore.kernel.org/linux-arm-kernel/20250708101206.70793-1-steffen@inno...
Does this work for you?
Hi Fabio, hi Steffen,
On Friday, 11 July 2025, 14:05:16 CEST, Fabio Estevam wrote:
Hi Christian,
On Fri, Jul 11, 2025 at 9:01 AM Christian Eggers ceggers@arri.de wrote:
Since commit 55d4980ce55b ("nvmem: core: support specifying both: cell raw data & post read lengths"), the aligned length (e.g. '8' instead of '6') is passed to the read_post_process callback. This causes that the 2 bytes following the MAC address in the ocotp are swapped to the beginning of the address. As a result, an invalid MAC address is returned and to make it even worse, this address can be equal on boards with the same OUI vendor prefix.
Fixes: 55d4980ce55b ("nvmem: core: support specifying both: cell raw data & post read lengths") Signed-off-by: Christian Eggers ceggers@arri.de Cc: stable@vger.kernel.org
Tested on i.MX6ULL, but I assume that this is also required for. imx-ocotp-ele.c (i.MX93).
Steffen has recently sent a similar fix:
https://lore.kernel.org/linux-arm-kernel/20250708101206.70793-1-steffen@inno...
Does this work for you?
your patch does obviously the same as mine. So the answer is 'yes'
regards, Christian
linux-stable-mirror@lists.linaro.org