[U-Boot] [PATCH 04/20] W1-EEPROM: Add an W1-EEPROM uclass for 1 wire EEPROMs

From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 04/20] W1-EEPROM: Add an W1-EEPROM uclass for 1 wire EEPROMs
Date: Thu, 2 Aug 2018 10:56:52 -0600	[thread overview]
Message-ID: <CAPnjgZ30j4vjaAOnzWAgW37Omgue8KykhmErvPPPU1FminYU8Q@mail.gmail.com> (raw)
In-Reply-To: <20180731020641.GH32145@bill-the-cat>

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 at 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