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;
 }
-- 
2.43.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@innosonix.de/

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@innosonix.de/
> 
> Does this work for you?
your patch does obviously the same as mine. So the answer is 'yes'

regards,
Christian