Re: [PATCH 1/3] mfd: ds1374: Introduce Dallas/Maxim DS1374 MFD core driver

[Alexandre Belloni]

On 22/06/2020 07:26:56-0700, Guenter Roeck wrote:
> On Mon, Jun 22, 2020 at 12:14:13PM +0100, Lee Jones wrote:
> > On Mon, 22 Jun 2020, Johnson CH Chen (éæå) wrote:
> > 
> > > Dallas/Maxim DS1374 is a counter designed to continuously count
> > > time in seconds. It provides an I2C interface to the host to
> > > access RTC clock or Alarm/Watchdog timer.
> > > 
> > > Add MFD Core driver, supporting the I2C communication to RTC and
> > > Watchdog devices.
> > > 
> > > Signed-off-by: Johnson Chen <johnsonch.chen@xxxxxxxx>
> > > ---
> > >  drivers/mfd/Kconfig  |  11 +++++
> > >  drivers/mfd/Makefile |   2 +
> > >  drivers/mfd/ds1374.c | 101 +++++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 114 insertions(+)
> > >  create mode 100644 drivers/mfd/ds1374.c
> > 
> > Not sure I see the point of this driver.
> > 
> 
> Not entirely sure either. Seems to me the idea is to use the watchdog
> subsystem for watchdog functionality, but that is just a guess and not
> really necessary (the conversion could be done in the rtc driver).
> I don't think the code as written works - the rtc code uses a mutex
> which the watchdog driver obviously isn't aware of. The mutex would
> have to be moved into the mfd code, with respective access functions.
> 
> Overall this adds a lot of complexity, and it seems the interdependencies
> between rtc and watchdog functionality are not well understood. Plus,
> other watchdog drivers have recently been added to other rtc clock chips,
> so this adds some inconsistencies in the rtc subsystem. Are we going
> to see this change for all those combined rtc/watchdog drivers ?
> If so, it might make sense to communicate that now to ensure consistency.
> 

I read the datasheet again and I agree the watchdog part can live in the
rtc driver. As only the RTC alarm and the watchdog are mutually
exclusive. I don't think an MFD driver is necessary. Converting the
current driver to the watchdog subsystem seems to be the correct way
forward.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com