From: Guenter Roeck <linux@roeck-us.net>
To: Chris Brandt <Chris.Brandt@renesas.com>
Cc: Wim Van Sebroeck <wim@iguana.be>,
Sebastian Reichel <sre@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Simon Horman <horms@verge.net.au>,
Geert Uytterhoeven <geert@linux-m68k.org>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>
Subject: Re: [PATCH v4 1/3] watchdog: add rza_wdt driver
Date: Thu, 2 Mar 2017 09:48:55 -0800 [thread overview]
Message-ID: <20170302174855.GD28554@roeck-us.net> (raw)
In-Reply-To: <SG2PR06MB11656393CB487F8413DAD58C8A280@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Thu, Mar 02, 2017 at 05:31:18PM +0000, Chris Brandt wrote:
> On Thursday, March 02, 2017, Guenter Roeck worte:
> > > > The above two lines are unnecessary.
> > >
> > > OK.
> > >
> > > #I'll assume you mean take out just the last sentence (2 lines), not
> > > both sentences (all 3 lines).
> > >
> > The two empty lines.
>
> Ooops! That makes more sense.
>
>
> > > > > + rate = clk_get_rate(priv->clk);
> > > > > + if (!rate)
> > > > > + return -ENOENT;
> > > > > +
> > > > > + /* Assume slowest clock rate possible (CKS=7) */
> > > > > + rate /= 16384;
> > > > > +
> > > >
> > > > The rate check should probably be here to avoid situations where
> > > > rate < 16384.
> > >
> > > Do I need that if it's technically not possible to have a 'rate' less
> > than 25MHz?
> > >
> > > These watchdogs HW are always feed directly from the peripheral clock
> > > and there is no such thing as a 16kHz peripheral block an any Renesas
> > SoC.
> > >
> > Following that line of argument, can clk_get_rate() ever return 0 ?
>
> In the DT binding, it says that a clock source is required to be present.
>
> If the user leaves out the "clocks =", then devm_clk_get will fail.
>
> If the user puts in some crazy value for "clocks = ", then maybe you could get
> 0 (assuming there is a valid clock node they made by themselves somewhere that
> runs at 0Hz).
> But in that extreme case, I think they deserve to have it crash and burn because
> who knows what they are doing.
>
But then there could also be a clock source with a rate of less than 16 kHz, as
wrong as it may be ?
Anyway, I disagree about the crash and burn. It isn't as if this would be really
fatal except for the watchdog driver. Bad data in devicetree should not result
in a system crash.
>
> > > > > + priv->wdev.max_hw_heartbeat_ms = (1000 * U8_MAX)/rate;
> > > >
> > > > space before and after /
> > >
> > > OK.
> > > #Funny because checkpatch.pl said it didn't like a space on one side
> > > but not the other, so I choose no spaces and it was happy. I'm way
> > > below 80 characters for that line so it doesn't matter to me.
> > >
> >
> > That would be a bug in checkpatch. coding style, chapter 3.1, still
> > applies.
> > Or at least I hope so.
>
> OK. Thank you for the clarification.
>
>
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + return 0;
> >
> > Also just
> > return ret;
>
> OK.
>
>
> > > > > +static int rza_wdt_remove(struct platform_device *pdev) {
> > > > > + struct rza_wdt *priv = platform_get_drvdata(pdev);
> > > > > +
> > > > > + watchdog_unregister_device(&priv->wdev);
> > > > > + iounmap(priv->base);
> > > >
> > > > iounmap is unnecessary (and wrong).
> > >
> > > Anything mapped with devm_ioremap_resource() automatically gets
> > > unmapped when the drive gets unloaded?
> >
> > That is the point of devm_ functions. It also means that you won't need a
> > remove function if you also use devm_watchdog_register_device().
>
> OK.
> I see that only 1 driver is using devm_watchdog_register_device (wdat_wdt.c), so
> maybe that is a new method.
>
Yes, it is quite new. Still, you are a bit behind. I count 19 users
in the mainline kernel.
Guenter
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
To: Chris Brandt <Chris.Brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Cc: Wim Van Sebroeck <wim-IQzOog9fTRqzQB+pC5nmwQ@public.gmane.org>,
Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>,
Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
"linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v4 1/3] watchdog: add rza_wdt driver
Date: Thu, 2 Mar 2017 09:48:55 -0800 [thread overview]
Message-ID: <20170302174855.GD28554@roeck-us.net> (raw)
In-Reply-To: <SG2PR06MB11656393CB487F8413DAD58C8A280-ESzmfEwOt/xoAsOJh7vwSm0DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Thu, Mar 02, 2017 at 05:31:18PM +0000, Chris Brandt wrote:
> On Thursday, March 02, 2017, Guenter Roeck worte:
> > > > The above two lines are unnecessary.
> > >
> > > OK.
> > >
> > > #I'll assume you mean take out just the last sentence (2 lines), not
> > > both sentences (all 3 lines).
> > >
> > The two empty lines.
>
> Ooops! That makes more sense.
>
>
> > > > > + rate = clk_get_rate(priv->clk);
> > > > > + if (!rate)
> > > > > + return -ENOENT;
> > > > > +
> > > > > + /* Assume slowest clock rate possible (CKS=7) */
> > > > > + rate /= 16384;
> > > > > +
> > > >
> > > > The rate check should probably be here to avoid situations where
> > > > rate < 16384.
> > >
> > > Do I need that if it's technically not possible to have a 'rate' less
> > than 25MHz?
> > >
> > > These watchdogs HW are always feed directly from the peripheral clock
> > > and there is no such thing as a 16kHz peripheral block an any Renesas
> > SoC.
> > >
> > Following that line of argument, can clk_get_rate() ever return 0 ?
>
> In the DT binding, it says that a clock source is required to be present.
>
> If the user leaves out the "clocks =", then devm_clk_get will fail.
>
> If the user puts in some crazy value for "clocks = ", then maybe you could get
> 0 (assuming there is a valid clock node they made by themselves somewhere that
> runs at 0Hz).
> But in that extreme case, I think they deserve to have it crash and burn because
> who knows what they are doing.
>
But then there could also be a clock source with a rate of less than 16 kHz, as
wrong as it may be ?
Anyway, I disagree about the crash and burn. It isn't as if this would be really
fatal except for the watchdog driver. Bad data in devicetree should not result
in a system crash.
>
> > > > > + priv->wdev.max_hw_heartbeat_ms = (1000 * U8_MAX)/rate;
> > > >
> > > > space before and after /
> > >
> > > OK.
> > > #Funny because checkpatch.pl said it didn't like a space on one side
> > > but not the other, so I choose no spaces and it was happy. I'm way
> > > below 80 characters for that line so it doesn't matter to me.
> > >
> >
> > That would be a bug in checkpatch. coding style, chapter 3.1, still
> > applies.
> > Or at least I hope so.
>
> OK. Thank you for the clarification.
>
>
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + return 0;
> >
> > Also just
> > return ret;
>
> OK.
>
>
> > > > > +static int rza_wdt_remove(struct platform_device *pdev) {
> > > > > + struct rza_wdt *priv = platform_get_drvdata(pdev);
> > > > > +
> > > > > + watchdog_unregister_device(&priv->wdev);
> > > > > + iounmap(priv->base);
> > > >
> > > > iounmap is unnecessary (and wrong).
> > >
> > > Anything mapped with devm_ioremap_resource() automatically gets
> > > unmapped when the drive gets unloaded?
> >
> > That is the point of devm_ functions. It also means that you won't need a
> > remove function if you also use devm_watchdog_register_device().
>
> OK.
> I see that only 1 driver is using devm_watchdog_register_device (wdat_wdt.c), so
> maybe that is a new method.
>
Yes, it is quite new. Still, you are a bit behind. I count 19 users
in the mainline kernel.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-03-02 18:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-02 13:57 [PATCH v4 0/3] watchdog: add wdt and reset for renesas r7s72100 Chris Brandt
2017-03-02 13:57 ` Chris Brandt
2017-03-02 13:57 ` [PATCH v4 1/3] watchdog: add rza_wdt driver Chris Brandt
2017-03-02 13:57 ` Chris Brandt
2017-03-02 14:56 ` Guenter Roeck
2017-03-02 14:56 ` Guenter Roeck
2017-03-02 15:38 ` Chris Brandt
2017-03-02 15:38 ` Chris Brandt
2017-03-02 17:11 ` Guenter Roeck
2017-03-02 17:31 ` Chris Brandt
2017-03-02 17:31 ` Chris Brandt
2017-03-02 17:48 ` Guenter Roeck [this message]
2017-03-02 17:48 ` Guenter Roeck
2017-03-02 18:22 ` Chris Brandt
2017-03-02 18:22 ` Chris Brandt
2017-03-02 18:39 ` Guenter Roeck
2017-03-02 18:39 ` Guenter Roeck
2017-03-03 10:16 ` Geert Uytterhoeven
2017-03-03 10:16 ` Geert Uytterhoeven
2017-03-02 13:57 ` [PATCH v4 2/3] watchdog: renesas-wdt: add support for rza Chris Brandt
2017-03-02 13:57 ` [PATCH v4 3/3] ARM: dts: r7s72100: Add watchdog timer Chris Brandt
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=20170302174855.GD28554@roeck-us.net \
--to=linux@roeck-us.net \
--cc=Chris.Brandt@renesas.com \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=horms@verge.net.au \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sre@kernel.org \
--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: link
Be 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.