linux-kernel - RE: [PATCH v2 0/4] nvmem: imx-ocotp-ele: fix reading from ELE OCOTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PAXPR04MB845905D963FC162FD46D4F2488362@PAXPR04MB8459.eurprd04.prod.outlook.com>
Date: Tue, 3 Dec 2024 06:47:22 +0000
From: Peng Fan <peng.fan@....com>
To: Sascha Hauer <s.hauer@...gutronix.de>, Srinivas Kandagatla
	<srinivas.kandagatla@...aro.org>, Shawn Guo <shawnguo@...nel.org>,
	Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam
	<festevam@...il.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC: "imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, stable <stable@...nel.org>
Subject: RE: [PATCH v2 0/4] nvmem: imx-ocotp-ele: fix reading from ELE OCOTP

> Subject: [PATCH v2 0/4] nvmem: imx-ocotp-ele: fix reading from ELE
> OCOTP
> 
> Commits b2ab0edaf484 ("arm64: dts: imx93: add nvmem property for
> fec1") and 0d4fbaffbdca ("arm64: dts: imx93: add nvmem property for
> eqos") introduced NVMEM cell bindings for reading MAC addresses
> from the ELE OCOTP. This doesn't work as expected due to bugs in the
> driver:
> 
> - imx_ocotp_reg_read() interprets the incoming offset as 32bit word
>   offset, but it really is in bytes which means the driver reads bogus
>   values whenever the offset is non zero
> - imx_ocotp_reg_read() reads wrong results when the offset is not 32bit
>   word aligned
> - MAC addresses are stored in reverse byte order in the ELE OCOTP, we
>   have to swap the order before passing them to the upper layer
> 
> This likely went through unnoticed because the bootloader normally
> adds the MAC addresses to the ethernet nodes and in this case they are
> preferred over the NVMEM addresses.
> 
> This series fixes these issues.
> 
> Sascha
> 
> Signed-off-by: Sascha Hauer <s.hauer@...gutronix.de>

For the patchset:
Reviewed-by: Peng Fan <peng.fan@....com>

Thanks,
Peng.