From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753784AbbEHNrH (ORCPT ); Fri, 8 May 2015 09:47:07 -0400 Received: from mail1.bemta5.messagelabs.com ([195.245.231.138]:62608 "EHLO mail1.bemta5.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752505AbbEHNrC convert rfc822-to-8bit (ORCPT ); Fri, 8 May 2015 09:47:02 -0400 X-Env-Sender: stwiss.opensource@diasemi.com X-Msg-Ref: server-5.tower-179.messagelabs.com!1431092804!34955508!1 X-Originating-IP: [94.185.165.51] X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked From: "Opensource [Steve Twiss]" To: Guenter Roeck , LINUXKERNEL , LINUXWATCHDOG , Wim Van Sebroeck CC: Alessandro Zummo , DEVICETREE , David Dajun Chen , Dmitry Torokhov , Ian Campbell , Kumar Gala , LINUXINPUT , Lee Jones , Liam Girdwood , Mark Brown , "Mark Rutland" , Pawel Moll , RTCLINUX , Rob Herring , Samuel Ortiz , Support Opensource Subject: RE: [PATCH V1 5/6] watchdog: da9062: DA9062 watchdog driver Thread-Topic: [PATCH V1 5/6] watchdog: da9062: DA9062 watchdog driver Thread-Index: AQHQeRyTN/8sGtEcQUaqI/lc3woPV51S3H4AgB9X5kA= Date: Fri, 8 May 2015 13:46:42 +0000 Message-ID: <6ED8E3B22081A4459DAC7699F3695FB7014B227F1A@SW-EX-MBX02.diasemi.com> References: <2afd9f55c71553186e99bfe386312f0c7d7501ed.1429280614.git.stwiss.opensource@diasemi.com> <55327DDA.4080003@roeck-us.net> In-Reply-To: <55327DDA.4080003@roeck-us.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.26.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18 April 2015 16:53 Guenter Roeck wrote: Hi Guenter, There were some missing explanations in my previous e-mails for some of your comments. Please find them below. During the da9062_wdt_probe() there were several ignored error paths and a missing cleanup . I intend to rectify this with the following: --- a/linux-next/v4.0/drivers/watchdog/da9062_wdt.c +++ b/linux-next/v4.0/drivers/watchdog/da9062_wdt.c @@ -232,8 +232,11 @@ static int da9062_wdt_probe(struct platform_device *pdev) dev_set_drvdata(&pdev->dev, wdt); irq = platform_get_irq_byname(pdev, "WDG_WARN"); - if (irq < 0) + if (irq < 0) { dev_err(wdt->hw->dev, "Failed to get IRQ.\n"); + ret = irq; + goto error; + } ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, da9062_wdt_wdg_warn_irq_handler, @@ -242,20 +245,23 @@ static int da9062_wdt_probe(struct platform_device *pdev) if (ret) { dev_err(wdt->hw->dev, "Failed to request watchdog device IRQ.\n"); + goto error; } ret = watchdog_register_device(&wdt->wdtdev); - if (ret < 0) + if (ret < 0) { dev_err(wdt->hw->dev, "watchdog registration incomplete (%d)\n", ret); + goto error; + } da9062_set_window_start(wdt); ret = da9062_wdt_ping(&wdt->wdtdev); if (ret < 0) - dev_err(wdt->hw->dev, - "failed to ping the watchdog (%d)\n", ret); + watchdog_unregister_device(&wdt->wdtdev); +error: return ret; } Also there was an explanation required for the confusing ping() function inside the driver probe() ... > > + da9062_wdt_ping(&wdt->wdtdev); [...] > That ping is asking for an explanation. Does it imply that the watchdog is > known to be running and cannot be stopped ? Pinging the DA9062 watchdog has no effect if it is disabled. But I guessed that in a real application if the watchdog -was- enabled from start-up then the first thing the driver needed to do was kick the watchdog. I could have put protection around it, say by reading the TWDSCALE bit for whether the watchdog was enabled, and that would have made it more explicit but in this case it wouldn't matter. This can be removed if you prefer. Regards, Steve