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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250602172327.2029611-1-abd.masalkhi@gmail.com>
Date: Mon,  2 Jun 2025 17:23:27 +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 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