From: Guenter Roeck <linux@roeck-us.net> To: Moritz Fischer <mdf@kernel.org>, linux-kernel@vger.kernel.org Cc: moritz.fischer@ettus.com, linux-watchdog@vger.kernel.org, wim@iguana.be, a.zummo@towertech.it, alexandre.belloni@free-electrons.com, rtc-linux@googlegroups.com, alex.williams@ni.com Subject: Re: [PATCH 0/2] DS1374 Watchdog fixes Date: Mon, 24 Apr 2017 22:03:45 -0700 [thread overview] Message-ID: <5f8fac22-4037-9983-436a-da8ff87d4b17@roeck-us.net> (raw) In-Reply-To: <1493071512-5718-1-git-send-email-mdf@kernel.org> On 04/24/2017 03:05 PM, Moritz Fischer wrote: > Hi all, > > this series fixes two issues that I ran into when trying to use the > watchdog part of the DS1374 on of our products. > > This series is basically a precursor to some further cleanup work, > that turns the DS1374 into a MFD device with an RTC and WDT in > separate drivers [1] each integrated in either the watchdog and > the rtc frameworks. > > I'm very unhappy with the CONFIG_DRV_RTC_DS1374_WDT way of enabling > the watchdog behavior and currently I'm investigating how to make > that work via DT. > > Watchdog maintainers, do you have an idea on how to do that in a > non breaking fashion? > Depends on what you mean with "non breaking". Just using the normal mfd mechanisms, ie define an mfd cell for each client driver, should work. Do you see any problems with that ? Either case, that doesn't seem to be a watchdog driver problem, or am I missing something ? > Thanks, > Moritz > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux.git/log/?h=wip/mfd-ds1374-rfc > > Moritz Fischer (2): > rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt > ticks > rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL > I don't really see the point of doing that if you plan to move the watchdog part of the driver into the watchdog directory. We for sure won't accept a watchdog driver that does not use the watchdog infrastructure. Regarding + /* WHY? */ + ds1374->wdd.timeout = t; Assuming you mean why the driver has to set the timeout value - not every watchdog hardware supports timeouts in multiples of 1 second. The driver is expected to set the value to the real timeout, not to the timeout asked for by the infrastructure. Guenter
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net> To: Moritz Fischer <mdf@kernel.org>, linux-kernel@vger.kernel.org Cc: moritz.fischer@ettus.com, linux-watchdog@vger.kernel.org, wim@iguana.be, a.zummo@towertech.it, alexandre.belloni@free-electrons.com, rtc-linux@googlegroups.com, alex.williams@ni.com Subject: [rtc-linux] Re: [PATCH 0/2] DS1374 Watchdog fixes Date: Mon, 24 Apr 2017 22:03:45 -0700 [thread overview] Message-ID: <5f8fac22-4037-9983-436a-da8ff87d4b17@roeck-us.net> (raw) In-Reply-To: <1493071512-5718-1-git-send-email-mdf@kernel.org> On 04/24/2017 03:05 PM, Moritz Fischer wrote: > Hi all, > > this series fixes two issues that I ran into when trying to use the > watchdog part of the DS1374 on of our products. > > This series is basically a precursor to some further cleanup work, > that turns the DS1374 into a MFD device with an RTC and WDT in > separate drivers [1] each integrated in either the watchdog and > the rtc frameworks. > > I'm very unhappy with the CONFIG_DRV_RTC_DS1374_WDT way of enabling > the watchdog behavior and currently I'm investigating how to make > that work via DT. > > Watchdog maintainers, do you have an idea on how to do that in a > non breaking fashion? > Depends on what you mean with "non breaking". Just using the normal mfd mechanisms, ie define an mfd cell for each client driver, should work. Do you see any problems with that ? Either case, that doesn't seem to be a watchdog driver problem, or am I missing something ? > Thanks, > Moritz > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux.git/log/?h=wip/mfd-ds1374-rfc > > Moritz Fischer (2): > rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt > ticks > rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL > I don't really see the point of doing that if you plan to move the watchdog part of the driver into the watchdog directory. We for sure won't accept a watchdog driver that does not use the watchdog infrastructure. Regarding + /* WHY? */ + ds1374->wdd.timeout = t; Assuming you mean why the driver has to set the timeout value - not every watchdog hardware supports timeouts in multiples of 1 second. The driver is expected to set the value to the real timeout, not to the timeout asked for by the infrastructure. Guenter -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
next prev parent reply other threads:[~2017-04-25 5:03 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-24 22:05 [PATCH 0/2] DS1374 Watchdog fixes Moritz Fischer 2017-04-24 22:05 ` [rtc-linux] " Moritz Fischer 2017-04-24 22:05 ` [PATCH 1/2] rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks Moritz Fischer 2017-04-24 22:05 ` [rtc-linux] " Moritz Fischer 2017-05-04 12:47 ` Alexandre Belloni 2017-05-04 12:47 ` [rtc-linux] " Alexandre Belloni 2017-04-24 22:05 ` [PATCH 2/2] rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL Moritz Fischer 2017-04-24 22:05 ` [rtc-linux] " Moritz Fischer 2017-05-04 12:47 ` Alexandre Belloni 2017-05-04 12:47 ` [rtc-linux] " Alexandre Belloni 2017-04-25 5:03 ` Guenter Roeck [this message] 2017-04-25 5:03 ` [rtc-linux] Re: [PATCH 0/2] DS1374 Watchdog fixes Guenter Roeck 2017-04-25 14:55 ` Moritz Fischer 2017-04-25 14:55 ` [rtc-linux] " Moritz Fischer 2017-04-25 16:17 ` Guenter Roeck 2017-04-25 16:17 ` [rtc-linux] " Guenter Roeck 2017-04-25 16:32 ` Alexandre Belloni 2017-04-25 16:32 ` [rtc-linux] " Alexandre Belloni 2017-04-25 16:58 ` Guenter Roeck 2017-04-25 16:58 ` [rtc-linux] " Guenter Roeck 2017-04-25 19:58 ` Moritz Fischer 2017-04-25 19:58 ` [rtc-linux] " Moritz Fischer 2017-04-25 20:22 ` Guenter Roeck 2017-04-25 20:22 ` [rtc-linux] " Guenter Roeck 2017-04-25 20:34 ` Moritz Fischer 2017-04-25 20:34 ` [rtc-linux] " Moritz Fischer 2017-04-25 21:05 ` Guenter Roeck 2017-04-25 21:05 ` [rtc-linux] " Guenter Roeck
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=5f8fac22-4037-9983-436a-da8ff87d4b17@roeck-us.net \ --to=linux@roeck-us.net \ --cc=a.zummo@towertech.it \ --cc=alex.williams@ni.com \ --cc=alexandre.belloni@free-electrons.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-watchdog@vger.kernel.org \ --cc=mdf@kernel.org \ --cc=moritz.fischer@ettus.com \ --cc=rtc-linux@googlegroups.com \ --cc=wim@iguana.be \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.