linux-kernel - Re: [PATCH v2 1/3] dt-bindings: Add Device Tree binding for ST M24LR control interface

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] [day] [month] [year] [list]

Message-ID: <20250601073147.2019266-1-abd.masalkhi@gmail.com>
Date: Sun,  1 Jun 2025 07:31:47 +0000
From: Abd-Alrhman Masalkhi <abd.masalkhi@...il.com>
To: krzk@...nel.org
Cc: abd.masalkhi@...il.com,
	arnd@...db.de,
	conor+dt@...nel.org,
	devicetree@...r.kernel.org,
	gregkh@...uxfoundation.org,
	krzk+dt@...nel.org,
	linux-kernel@...r.kernel.org,
	robh@...nel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: Add Device Tree binding for ST M24LR control interface

Hi Krzysztof,

Thank you for your review.

> Drop quotes. So this is I2C mux or EEPROM?

The system parameter sector and the EEPROM do not share a continuous address
space, each starts at address 0 and spans its own internal region. This
overlapping addressing creates ambiguity if treated as a single memory space.

Additionally, there's a synchronization issue: during multi-page writes to
the EEPROM, if a control command (e.g., a lock) is issued mid-operation,
it may result in partial or inconsistent writes.

To address both challenges, the driver uses a mux-based design:

1- The m24lr_ctl driver acts as a gate for EEPROM access.

2- It provides exclusive, serialized access and handles the control interface.

3- The EEPROM itself is exposed as a child node using the standard at24 driver.

This separation ensures reliable operation and a clean, maintainable
architecture.

> That's not a misc device, but eeprom. Place it in appropriate directory.

Given the above, I'm unsure if placing it under eeprom/ is the best choice.
Would you suggest still placing it eeprom or under somewhere else maybe i2c/
(e.g., i2c/i2c-mux-stm24lr.yaml)?

Best regards,
Abd-Alrhman Masalkhi