On Fri, Feb 20, 2015 at 1:25 PM, Srinivas KandagatlaYep, I will do that in next version.
On 20/02/15 17:21, Rob Herring wrote:
On Thu, Feb 19, 2015 at 11:08 AM, Srinivas Kandagatla
From: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>
Up until now, EEPROM drivers were stored in drivers/misc, where they all
duplicate pretty much the same code to register a sysfs file, allow
users to access the content of the devices they were driving, etc.
This was also a problem as far as other in-kernel users were involved,
the solutions used were pretty much different from on driver to another,
was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.
Having regmap interface to this framework would give much better
abstraction for eeproms on different buses.
Signed-off-by: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>
[srinivas.kandagatla: Moved to regmap based and cleanedup apis]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx>
.../devicetree/bindings/eeprom/eeprom.txt | 48 ++++
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/eeprom/Kconfig | 19 ++
drivers/eeprom/Makefile | 9 +
drivers/eeprom/core.c | 290
include/linux/eeprom-consumer.h | 73 ++++++
include/linux/eeprom-provider.h | 51 ++++
Who is going to be the maintainer for this?
Am happy to be one.
So please add a MAINTAINERS entry.
+= Data consumers =
+eeproms: List of phandle and data cell specifier triplet, one triplet
+ for each data cell the device might be interested in. The
+ triplet consists of the phandle to the eeprom provider, then
+ the offset in byte within that storage device, and the length
+ in byte of the data we care about.
The problem with this is it assumes you know who the consumer is and
that it is a DT node. For example, how would you describe a serial
Correct me if I miss understood.
Is serial number any different?
Am hoping that the eeprom consumer would be aware of offset and size of
serial number in the eeprom
Cant the consumer do:
eeproms = <&at24 0 4>;
eeprom-names = "device-serial-number";
Yes, but who is "eeprom-consumer"? DT nodes generally describe a h/w
block, but it this case, the consumer depends on the OS, not the h/w.
I'm not saying you can't describe where things are, but I don't thinkI agree, the data layout is very specific to platform and could vary in complexity.
you should imply who is the consumer and doing so is unnecessarily
Also, the layout of EEPROM is likely very much platform specific. Some
could have a more complex structure perhaps with key ids and linked
There are pros and cons doing it as list of keys.
I would do something more simple that is just a list of keys and their
location like this:
device-serial-number = <start size>;
key1 = <start size>;
key2 = <start size>;