lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200622150126.GJ131826@piout.net>
Date:   Mon, 22 Jun 2020 17:01:26 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Lee Jones <lee.jones@...aro.org>,
        Johnson CH Chen (陳昭勳) 
        <JohnsonCH.Chen@...a.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>
Subject: Re: [PATCH 1/3] mfd: ds1374: Introduce Dallas/Maxim DS1374 MFD core
 driver

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@...a.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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ