Received: by 10.192.165.148 with SMTP id m20csp1509387imm; Thu, 10 May 2018 11:50:26 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo0TiwpGsVvi55zPZUCMvy60uaLAic7NvzkyP6H3kzDBrSNNK5JADzwE7OxHzsSWOOsakBm X-Received: by 2002:a17:902:108a:: with SMTP id c10-v6mr2453624pla.111.1525978226756; Thu, 10 May 2018 11:50:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525978226; cv=none; d=google.com; s=arc-20160816; b=DrfqJD+e1D1Ue8WeEkl6YOJl4cHVuhNdrx96Rm7bAEE5sNwfJ941aGzKrY3/upsHIP +2sAmYZXyH8QJu3ARuHrvwZohH5p3he3JUT18I/B50OMyrOMiAjMAw1iuREDSbCcI5HZ f0D9Yzc0ou1geofsm+AUiTY43qtLcBOnGg9f3FfBGLMtlUoIuwgOnxhmh5WEvkiTZYuw FDb1SWm/CbW3HgX3rCveFDnriBRnUI+VOnbixWbnJEgd/FYLg2/MX7artAHTSVQWIign B4wJUE5tPOapuJHdbeTjaxfj6WmOdOJ0t4VZMCdShF9LCR55xNYYPnRBWgqldANYuF9u JHcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:references:in-reply-to :message-id:date:subject:cc:to:from:arc-authentication-results; bh=5mIewojUX8aQ5nd9AkvTY9dhQJaG6ywPTi2lZn/AN8E=; b=Qnx0QJUA6ZvvdTrPg3THyQQ7DHBFxhYuD3lmmEaZpR4Fdzy6aNoasHgfQqVwZYWUjo q3UZBW5RqOIRhi2oK784pUx2QLNdawSNO09T79nv3VuagQ3UEajhRVQHn9XDD05cqrEP PWnknXk9H2SgWBTUE9eBH0LyUnbb86vQqX1tGJr5ydkiihGBfTXXzvcoSM1TCBe58o1z oxE8NHE9RyhtANbNquEVTWFxbWmFijfVGdLOEszJw1DHORiODw1ej+rWc48TaSxmvpCO IuX51wCMPvfpBEU4aaJlt2jgs9olrpopxlY40E4ONJ9daxUcj5t5389CYWauju5cnr1g hDFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@crapouillou.net header.s=mail header.b=GVr2nG0r; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s204-v6si1137748pgs.164.2018.05.10.11.50.12; Thu, 10 May 2018 11:50:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@crapouillou.net header.s=mail header.b=GVr2nG0r; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752055AbeEJStd (ORCPT + 99 others); Thu, 10 May 2018 14:49:33 -0400 Received: from outils.crapouillou.net ([89.234.176.41]:55952 "EHLO crapouillou.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750881AbeEJSs1 (ORCPT ); Thu, 10 May 2018 14:48:27 -0400 From: Paul Cercueil To: Guenter Roeck , Rob Herring , Mark Rutland , Ralf Baechle , James Hogan Cc: Wim Van Sebroeck , Mathieu Malaterre , linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Paul Cercueil Subject: [PATCH v3 4/8] watchdog: JZ4740: Drop module remove function Date: Thu, 10 May 2018 20:47:47 +0200 Message-Id: <20180510184751.13416-4-paul@crapouillou.net> In-Reply-To: <20180510184751.13416-1-paul@crapouillou.net> References: <20180510184751.13416-1-paul@crapouillou.net> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1525978105; bh=5mIewojUX8aQ5nd9AkvTY9dhQJaG6ywPTi2lZn/AN8E=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References; b=GVr2nG0rjww+2YVMd6BJ42oDclMV8ZGMxnPamvElA0v+fFDHPuoqMlxwfofvhQpw43Xu6F7rRyCzsOYLHrIIE+SgLIaSqYN7+G7oyB8hPYnn2rQlb8yaDSaQQm5LjTXB14GZpvPG3yv6Ql0xAHTKDYSh/2oPrnSYDaHt2iNdNLM= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When the watchdog was configured for nowayout, and after the userspace watchdog daemon closed the dev node without sending the magic character, unloading this module stopped the watchdog hardware, which was clearly a problem. Besides, unloading the module is not possible when the userspace watchdog daemon is running, so it's safe to assume that we don't need to stop the watchdog hardware in the jz4740_wdt_remove() function. For this reason, the jz4740_wdt_remove() function can then be dropped alltogether. Signed-off-by: Paul Cercueil Reviewed-by: Guenter Roeck --- drivers/watchdog/jz4740_wdt.c | 8 -------- 1 file changed, 8 deletions(-) v2: New patch in this series v3: No change diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c index b8b015a7d045..ec4d99a830ba 100644 --- a/drivers/watchdog/jz4740_wdt.c +++ b/drivers/watchdog/jz4740_wdt.c @@ -206,16 +206,8 @@ static int jz4740_wdt_probe(struct platform_device *pdev) return 0; } -static int jz4740_wdt_remove(struct platform_device *pdev) -{ - struct jz4740_wdt_drvdata *drvdata = platform_get_drvdata(pdev); - - return jz4740_wdt_stop(&drvdata->wdt); -} - static struct platform_driver jz4740_wdt_driver = { .probe = jz4740_wdt_probe, - .remove = jz4740_wdt_remove, .driver = { .name = "jz4740-wdt", .of_match_table = of_match_ptr(jz4740_wdt_of_matches), -- 2.11.0