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
next prev parent 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).