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 again for yourfeedback, it's been very helpful in
understanding how best to write the binding file represent
this device.

>> 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:
>
> So these are just two different addresses. I already commented on this.
> This is not I2C mux but a device with two addresses.

I'd like to clarify one point before proceeding further, If I remove
the i2c-mux usage from the binding file, as your recommendation, does
this also imply that I should stop using the i2c-mux API in my driver
implementation itself? and treat this as a multi-function device, or
Is it acceptable to keep the current driver logic as-is, while limiting
the change to just fixing the binding and device tree representation?

and if only the binding file, should i represent it as the following:

  eeprom-ctl@57 {
  #address-cells = <1>;
  #size-cells = <0>;
  compatible = "st,m24lr04e-r";
  reg = <0x57>;

  }

Best regards,
Abd-Alrhman Masalkhi