linux-watchdog.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Johnson CH Chen (陳昭勳)" <JohnsonCH.Chen@moxa.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Guenter Roeck <linux@roeck-us.net>
Cc: Lee Jones <lee.jones@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Wim Van Sebroeck <wim@linux-watchdog.org>
Subject: RE: [PATCH 1/3] mfd: ds1374: Introduce Dallas/Maxim DS1374 MFD core driver
Date: Tue, 23 Jun 2020 07:12:42 +0000	[thread overview]
Message-ID: <HK2PR01MB3281B2BC29C32315759B7ED2FA940@HK2PR01MB3281.apcprd01.prod.exchangelabs.com> (raw)
In-Reply-To: <20200622150126.GJ131826@piout.net>

Hi,
 
> 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@moxa.com>
> > > > ---
> > > >  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.
> 
Thanks for your good thinking. If we want to add watchdog function such as 
"nowayout" to the driver, it's good to try to upstream this in rtc-ds1374.c in 
rtc subsystem?

It seems like more complexity if we want to separate rtc and watchdog for one 
chip supports. For one chip which supports rtc/alarm and watchdog, can we 
upstream rtc/alarm and watchdog functions to these driver no matter where it's 
in rtc or watchdog subsystem?


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

Best regards,
Johnson

  reply	other threads:[~2020-06-23  7:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-22 10:03 [PATCH 1/3] mfd: ds1374: Introduce Dallas/Maxim DS1374 MFD core driver Johnson CH Chen (陳昭勳)
2020-06-22 11:14 ` Lee Jones
2020-06-22 14:26   ` Guenter Roeck
2020-06-22 15:01     ` Alexandre Belloni
2020-06-23  7:12       ` Johnson CH Chen (陳昭勳) [this message]
2020-06-22 15:38 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=HK2PR01MB3281B2BC29C32315759B7ED2FA940@HK2PR01MB3281.apcprd01.prod.exchangelabs.com \
    --to=johnsonch.chen@moxa.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=wim@linux-watchdog.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).