Re: [PATCH 1/2] Create eeprom_dev hardware class for EEPROM devices

[Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>]

On 01/22/2014 09:47 AM, Curt Brune wrote:
> Create a new hardware class under /sys/class/eeprom_dev
> 
> EEPROM drivers can register their devices with the eeprom_dev class
> during instantiation.
> 
> The registered devices show up as:
> 
>   /sys/class/eeprom_dev/eeprom0
>   /sys/class/eeprom_dev/eeprom1
>   ...
>   /sys/class/eeprom_dev/eeprom[N]
> 
> Each member of the eeprom class exports a sysfs file called "label",
> containing the label property from the corresponding device tree node.
> 
> Example:
> 
>   /sys/class/eeprom_dev/eeprom0/label
> 
> If the device tree node property "label" does not exist the value
> "unknown" is used.
> 
> Userspace can use the label to identify what the EEPROM is for.

I will be using the at24 driver (most likely -- the SPD protocol is so
simple that it may be easier to use the raw SMBUS API) to talk to
NV-DIMMs.  For this purpose, I really need to know that a given EEPROM
is the EEPROM attached to a particular DIMM.  I wrote some code (search
for "DIMM bus", in limbo) that kind of solves this problem, but it's not
pretty.

In general, I suspect this will have the issue that EDID, SPD, etc.
eeprom devices will get all confused.

Ideally there would be a way to express the logical topology.  In the
case of NV-DIMMs there's a DIMM.  That DIMM exposes some memory (which
isn't really part of the driver model), some temperature sensors, an
SPD, and some other stuff.  The DIMM as a whole lives in a DIMM slot.

Unfortunately, the kernel has no real awareness of what's going on.  The
arch code just sees it as memory (without really associating it with a
DIMM) and the EDAC driver and things like dmidecode do their own thing.

The same issue shows up when sensors-detect offers to scan all the i2c
busses on the ports on my graphics card for things like motherboard
voltage sensors.

Unfortunately, I don't think that using a device tree label really helps
here, especially because none of the machines I care about use (or are
likely to ever use) device trees.


--Andy