devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Cartwright <joshc@codeaurora.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Wim Van Sebroeck <wim@iguana.be>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-watchdog@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Kumar Gala <galak@codeaurora.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] watchdog: qcom: add support for KPSS WDT
Date: Thu, 18 Sep 2014 22:24:16 -0500	[thread overview]
Message-ID: <20140919032416.GE3749@joshc.qualcomm.com> (raw)
In-Reply-To: <541B97CD.60400@roeck-us.net>

On Thu, Sep 18, 2014 at 07:41:17PM -0700, Guenter Roeck wrote:
> On 09/18/2014 03:26 PM, Josh Cartwright wrote:
> >Add a driver for the watchdog timer block found in the Krait Processor
> >Subsystem (KPSS) on the MSM8960, APQ8064, and IPQ8064.
> >
> >Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> 
> Hi Josh,
> 
> comments inline.

Thanks for taking a look!

[..]
> >+static int qcom_watchdog_probe(struct platform_device *pdev)
> >+{
> >+	struct qcom_wdt *wdt;
> >+	struct resource *res;
> >+	u32 tmp;
> >+	int ret;
> >+
> >+	wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
> >+	if (!wdt)
> >+		return -ENOMEM;
> >+
> >+	platform_set_drvdata(pdev, wdt);
> >+
> >+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >+	wdt->base = devm_ioremap_resource(&pdev->dev, res);
> >+	if (IS_ERR(wdt->base))
> >+		return PTR_ERR(wdt->base);
> >+
> >+	ret = of_property_read_u32(pdev->dev.of_node, "clock-frequency", &tmp);
> >+	if (ret) {
> >+		dev_err(&pdev->dev, "unable to get clock-frequency\n");
> >+		return ret;
> >+	}
> >+
>
> You might want to use a clock property here, and the complete sequence of
> 	devm_clk_get
> 	clk_prepare_enable
> 	clk_disable_unprepare
> 	clk_get_rate

Agreed.  I think this would be ideal.  I'll need to take a closer look
at how this thing is clocked, and how/if the clocks are currently
being modelled.

> >+	wdt->freq = tmp;
> >+
> >+	wdt->wdd.dev = &pdev->dev;
> >+	wdt->wdd.info = &qcom_wdt_info;
> >+	wdt->wdd.ops = &qcom_wdt_ops;
> >+	wdt->wdd.min_timeout = 1;
> >+	wdt->wdd.max_timeout = 0x10000000U / wdt->freq;
>
> As written, wdt->freq can be 0, which results in a nice division by zero here.

Indeed.  I'll add a check.

> >+	watchdog_init_timeout(&wdt->wdd, 0, &pdev->dev);
>
> That leaves you with no default timeout if timeout-sec is not set in devicetree,
> which if I understand the code correctly might result in an immediate reset.
> Is this really what you want to happen ?

I think I'd like to handle timeout-sec being unspecified as an error at
probe.  If someone explicitly sets timeout-sec = <0>, then they get what
they ask for.  I'll take another look to see how to make this happen.

> >+
> >+	ret = watchdog_register_device(&wdt->wdd);
> >+	if (ret) {
> >+		dev_err(&pdev->dev, "failed to register watchdog\n");
> >+		return ret;
> >+	}
> >+
> >+	return 0;
> >+}
> >+
> >+static const struct of_device_id qcom_wdt_of_table[] = {
> >+	{ .compatible = "qcom,kpss-wdt-msm8960", },
> >+	{ .compatible = "qcom,kpss-wdt-apq8064", },
> >+	{ .compatible = "qcom,kpss-wdt-ipq8064", },
> >+	{ },
> >+};
> >+MODULE_DEVICE_TABLE(of, qcom_wdt_of_table);
> >+
> >+static struct platform_driver qcom_watchdog_driver = {
> >+	.probe	= qcom_watchdog_probe,
>
> No remove function ?
>
> Yes, you don't need it, because the driver can only be built into the kernel,
> but there is a practical impact: It means the driver must always be built
> into the kernel even if the image is supposed to be used on different systems,
> some of which may not support this specific watchdog.
>
> Sure, you might say that you don't care about images supporting more than one
> hardware, but the tendency seems to be multi-target images nowadays.

This was motivated by the addition of the restart_handler bits in patch
3.  For some reason I was thinking there were race conditions between
module unloading/the restart_handler mechanism, but looking at it again,
I'm not so sure.  Is it safe to implement these handlers in modules?  If
so, I'll revisit this.

Thanks again,
  Josh

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2014-09-19  3:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 22:26 [PATCH 0/3] watchdog: add support for QCOM WDT Josh Cartwright
2014-09-18 22:26 ` [PATCH 1/3] watchdog: qcom: add support for KPSS WDT Josh Cartwright
     [not found]   ` <32d17907ad1dfdcafe4e76f33adc2ff22631cd28.1411078425.git.joshc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-09-19  2:41     ` Guenter Roeck
2014-09-19  3:24       ` Josh Cartwright [this message]
2014-09-19  3:41         ` Guenter Roeck
2014-09-19 16:25           ` Josh Cartwright
2014-09-19 16:56             ` Guenter Roeck
2014-09-18 22:27 ` [PATCH 2/3] watchdog: qcom: document device tree bindings Josh Cartwright

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=20140919032416.GE3749@joshc.qualcomm.com \
    --to=joshc@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=robh+dt@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 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).