Hi, On 30 July 2018 at 20:06, Tom Rini <[email protected]> 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 <[email protected]> >> >> >> >>We might want to access data stored onto one wire EEPROMs. >> >>Create a framework to provide a consistent API. >> >> >> >>Signed-off-by: Maxime Ripard <[email protected]> >> >>[[email protected]: reworked patch] >> >>Signed-off-by: Eugen Hristev <[email protected]> >> >>--- >> >> 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
