Hi,
On 30 July 2018 at 20:06, Tom Rini trini@konsulko.com wrote:
On Mon, Jul 30, 2018 at 11:54:51AM +0300, Eugen Hristev wrote:
On 20.07.2018 17:28, Maxime Ripard wrote:
Hi Eugen,
Thanks for giving those patches another shot.
On Thu, Jul 19, 2018 at 12:57:52PM +0300, Eugen Hristev wrote:
From: Maxime Ripard maxime.ripard@free-electrons.com
We might want to access data stored onto one wire EEPROMs. Create a framework to provide a consistent API.
Signed-off-by: Maxime Ripard maxime.ripard@bootlin.com [eugen.hristev@microchip.com: reworked patch] Signed-off-by: Eugen Hristev eugen.hristev@microchip.com
drivers/Kconfig | 2 ++ drivers/Makefile | 1 + drivers/w1-eeprom/Kconfig | 17 +++++++++++ drivers/w1-eeprom/Makefile | 2 ++ drivers/w1-eeprom/w1-eeprom-uclass.c | 56 ++++++++++++++++++++++++++++++++++++ include/dm/uclass-id.h | 1 + include/w1-eeprom.h | 28 ++++++++++++++++++ 7 files changed, 107 insertions(+) create mode 040000 drivers/w1-eeprom create mode 100644 drivers/w1-eeprom/Kconfig create mode 100644 drivers/w1-eeprom/Makefile create mode 100644 drivers/w1-eeprom/w1-eeprom-uclass.c create mode 100644 include/w1-eeprom.h
I believe that we shouldn't have a framework solely for 1-wire EEPROMs, but for EEPROMs, connected to any bus.
The 1-Wire EEPROMs all behave pretty much the same, so we'll probably only see a single driver within that framework. And at the same time, we'll want to have a consistent interface to access all the EEPROMs, no matter on which bus they sit on.
Hello,
I worked this series using the original implementation as a starting point: having the eeproms on different subsystems (i2c and onewire).
The different types of eeproms have only the name in common as I see it, and the way to access them is totally different: two different type of buses, so uniting them is just for the namesake ?
One option is to have them separately, as we have spi, i2c memories , etc; Or, unite them under a single subsystem for eeproms, and have one driver for i2c eeproms and one for w1 eeproms, trying to make the same API to access them, and hide the bus specific differences.
Question for maintainers: which is the best direction to go, so I can rework the series accordingly ?
It would be nice if we had a generic eeprom command that wasn't bus-centric. Unfortunately we have an eeprom command that IS bus centric and not easily extended to working on all appropriate buses. So to me, starting out by handing w1 eeproms under w1 seems OK. And we can put it on the TODO list to make cmd/eeprom.c parse <bus> as perhaps "BUSTYPE:number" so we could do eeprom w1:0 ... or eeprom i2c:0 ... and so forth.
That makes sense to me.
We could provide some sort of read/write device supported by SPI, I2C, 1wire, etc. in principle. I don't think anyone has attempted it yet.
Regards, Simon