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

[Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>]

Hi Krzysztof,

Thank you for the detailed feedback.

> Do not send next version while the discussion is still happening.

You're right, I sent the updated version too early while discussion was
still ongoing. I'll hold off on sending further revisions until the current
points are fully resolved.

> Full path, so /schemas/i2c/i2c-mux.... but this is not an i2c mux, at
> least not in your description, so something feels incomplete or incorrect.

A Brief Overview of the Device:

The M24LR series is a dual-interface EEPROM with both I2C and ISO/IEC 15693
RF support. While it is technically an EEPROM, it also exposes a control
interface over I2C via a second address, which is used to manage features
such as password protection, energy harvesting configuration, and UID access.
This secondary interface is not memory-mapped like traditional EEPROMs, which
is why I initially considered separating the control aspect in the software.

How to Access the EEPROM and the System Parameter Sector?

According to the datasheet for the M24LR04E-R, the E2 bit must be set
appropriately in the I2C device select code to distinguish between EEPROM
access and control access.

What is E2?
E2 is a bit in the I2C device select code. It determines which internal
function of the chip is being accessed.

Device Select Code Format:
Bit:                b7  b6  b5  b4  b3  b2  b1  b0
Value:              1   0   1   0   E2  1   1   R/W

To access the EEPROM memory, E2 (b3) should be 0:

Device Select Code Format:
Bit:                b7  b6  b5  b4  b3  b2  b1  b0
Value:              1   0   1   0   0  1   1   R/W

To access the system control interface, E2 (b3) should be 1:

Device Select Code Format:
Bit:                b7  b6  b5  b4  b3  b2  b1  b0
Value:              1   0   1   0   0  1   1   R/W

Is This a Gate?
Correct me if I'm wrong, but to me this behavior resembles a form of gate,
instead of using a separate hardware pin to access the EEPROM, the chip
encodes this selection in the I2C device address. However, the datasheet
does not explicitly mention anything about a "gate" or "mux," which is
why I've been careful to not label it as an I2C gate in the binding.

That said, I see it as a kind of implicit I2C mux (of type gate), where
the chip use the 0x57 address as in the example and to select the internal
EEPROM we just reset the b3 in the device select code.

Why This View Matters in my driver design:

Looking at the device from this perspective has helped me keep the driver
design cleaner while keeping the synchronization issue in mind:

1- Avoiding code duplication (such as rewriting parts of the at24 driver).
2- Ensuring concurrent access to EEPROM and control areas is properly
   handled and isolated.
3- Representing the dual-role nature of the chip more explicitly.

> What does "r" stand for?

The r in st,m24lr04e-r stands for RF, these are the RF-enabled variants
of the M24LR series, as specified by STMicroelectronics.

> Do not need '>' unless you need to preserve formatting.

I'll remove the | and > where formatting preservation is not needed.

> Don't repeat constraints in free form text. I already asked for this.

I'll avoid repeating constraints in free-form text.

> Where is the second address? It is supposed to be here.

>> +          #size-cells = <0>;
>> +
>> +          eeprom@53 {
>> +            compatible = "atmel,24c04";
>> +            reg = <0x53>;

Here is the second address is 0x53, to select the EEPROM 

I appreciate your feedback.

Best regards,
Abd-Alrhman Masalkhi