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

[Eugen Hristev]

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 at 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 at bootlin.com>
>> [eugen.hristev at microchip.com: reworked patch]
>> Signed-off-by: Eugen Hristev <eugen.hristev at 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 ?

Thanks,
Eugen
> 
> Maxime
>