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.rip...@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.rip...@bootlin.com> > >>[eugen.hris...@microchip.com: reworked patch] > >>Signed-off-by: Eugen Hristev <eugen.hris...@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. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
