Re: [PATCH v3 3/3] ABI: sysfs: add documentation for ST M24LR EEPROM and control interface

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

Hi Greg,

> > >> +What:           /sys/bus/i2c/devices/<busnum>-<primary-addr>/sss<N>
> > >> +Date:           2025-05-31
> > >> +KernelVersion:  6.16
> > >> +Contact:        Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
> > >> +Description:
> > >> +                Read/write attribute representing the Sector Security Status
> > >> +                (SSS) byte for EEPROM sector <N> in the M24LR chips. Each sector
> > >> +                has one SSS byte, which defines I2c and RF access control via a
> > >> +                combination of protection and password settings.
> > >> +                Format:
> > >> +                  - Read: returns a 8-bit hexadecimal value followed by a
> > >> +                          newline
> > >> +                  - Write: requires exactly one or two hexadecimal digits
> > >> +                      - No "0x" prefix, whitespace, or trailing newline
> > >> +                      - Case-insensitive
> > >> +
> > >> +                Notes:
> > >> +                  - Refer to the M24LR chip datasheet for full bit definitions
> > >> +                    and usage
> > >> +                  - Write access requires prior password authentication in I2C
> > >> +                    mode
> > >
> > > How "deep" does this sysfs tree get here?  This feels like the wrong api
> > > for read/write to the device, just do it with a single binary file if
> > > you really want a "passthrough" way to get to the hardware.
> > 
> > The depth of the sysfs tree depends on the M24LR variant. For example,
> > the M24LR04E-R has 4 sectors, resulting in 4 entries: sss0 through sss3.
> > 
> > I understand the concern about exposing multiple sysfs entries. The
> > reason for this design is that each sector has its own SSS byte, and
> > separating them helps reflect the per-sector nature of the access
> > control. That said, I'm open to refactoring this to expose the SSS
> > area via a single binary file if that's more in line with expected
> > kernel interfaces.
> 
> Who and what is going to be talking to this device through this
> interface?  Is this unique and special to ONLY this one chip/device or
> does it fit in with all other types of this device (i.e. eeproms)?  You
> can't create a userspace api without actually having a user at all, so
> if there is no userspace code using this, why even have this?

A userspace application specific to the M24LR series is intended to
interface with this driver. The M24LR devices support dual access
to the EEPROM: via I2C and over RFID. The purpose of exposing the
Sector Security Status (SSS) registers to userspace is to provide
dynamic control over when and how the EEPROM is accessible to an
RFID reader. This allows userspace to decide whether to permit or
deny EEPROM reads/writes via RFID, or to configure protection for
specific memory sectors.

The SSS registers define per-sector read/write permissions and
password protection, directly determining how external RFID readers
interact with the tag. By exposing this configuration through sysfs,
userspace software can modify RFID access behavior at runtime for
example, to enable secure provisioning workflows, implement time-based
access, or prevent unauthorized access after setup.

Given that this is a per-sector control mechanism unique to the M24LR
series, would exposing the entire SSS region via a single binary sysfs
file be considered more appropriate than individual attributes per sector?

Best regards,
Abd-Alrhman Masalkhi