Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1413079ybv; Sun, 23 Feb 2020 06:09:44 -0800 (PST) X-Google-Smtp-Source: APXvYqyLWfBRSBh4g20yYKZRZ9+sTh9Ukwh+3KqD/48P/OdXYBLN6rCvkZj+MzDGItxS+vCWcNln X-Received: by 2002:aca:3f43:: with SMTP id m64mr9090035oia.165.1582466984763; Sun, 23 Feb 2020 06:09:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582466984; cv=none; d=google.com; s=arc-20160816; b=ZSOHNnU8L9NYEgMy56RNzIPb0rue8y1+BoA/n1dJW1AzpbzGpijHW21gmy5wIML1HF FZ5dPKEPD3ZHMzUBpE3S5yrEZ4ccj6f50tUzfdh1ZJbbb/wj2IbD46G6SmI70Xx3Hk3j krAszC4zuxp2apsXLsyzLoNPjfvZ/IGIh5YnRN/TNEyoPuemuGUl0ISDwVwEI9EQNCns rrGIpNuF4d2BgZPT+8ogS1t7D+2OoKbnx3L7Dlr5BCGtVCaj3jnLhymHMVtJtqw2doCB 3NtE364UMBbFTy91YitLV8D2RmSA8g0R/atmmUkDniVmgT1juZ5OpgeSNLTivAxDgM7Z D9RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=XD21Leo6kLR5qlxiWjZstdOKlqxFlzQ6WlHQ2R8Sm0g=; b=SZDFsLqqzFdwwN/TBQG09kaS/+8CsDmSDUafnBVaShnc+YqJDGJ5T0sXVJyq1J+SQ3 wREE6W3DKXVcNSkXyOeK3O+wTP3vF+3IxpG6FGHRSvdti115AEtqF0mOCd4Rh7yeBMCT 9hN2KRvnqMRzbc+WaYd3FFlPvlW4+yd2ra3G0CSYjQXqvFIEYox8fdqEXv78MqXNaS5H Da9D6D/xbN3qERDXZ+VDxy2BatZMoIx9SXYtQ95ZfsmssWEhby3RXcWcmAF+4S3tNh53 /WH7nnrjRjQ+8IkbnA9rcCR2bh7tKyju5EIE7gKzB17L8xgupTvSlPXRICUcbRxYT6DV Spxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=VVCuNFRs; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h22si3226152oie.189.2020.02.23.06.09.32; Sun, 23 Feb 2020 06:09:44 -0800 (PST) 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=fail header.i=@gmail.com header.s=20161025 header.b=VVCuNFRs; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727024AbgBWOIJ (ORCPT + 99 others); Sun, 23 Feb 2020 09:08:09 -0500 Received: from mail-pj1-f65.google.com ([209.85.216.65]:51995 "EHLO mail-pj1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726534AbgBWOIJ (ORCPT ); Sun, 23 Feb 2020 09:08:09 -0500 Received: by mail-pj1-f65.google.com with SMTP id fa20so2873629pjb.1; Sun, 23 Feb 2020 06:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XD21Leo6kLR5qlxiWjZstdOKlqxFlzQ6WlHQ2R8Sm0g=; b=VVCuNFRsY5ktZtLIbg4z3N8VwcmqYJBXpWys4vupuwKDJZlvbzDme9m7YEjlXPgiA9 81UmvGYiq1GjTqCaZAxN3K2/jbxnvHqXhK1yMjGMh01Y09EhgWshlqZfWgZA7XUorjUL 5OfNgTpl0eic4MB/ueEz/STh6MpbFRheO103tdYu9lqhRbp+ukkHvp5EkVzbK5RKDRWi R6nGaa3fh8ZOI7mOkNh6LNhI+Hq1+p4ukyvrxXrKv6dcsMGZPikHDBI/JH0XOyBg0oCC r3tNVn8xKnwJ17JhhE81csZ5xm5Ot8vJ2gYSK0fTsG0n5VAHokfCqQs68d7oGKklBoVJ 7Okw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XD21Leo6kLR5qlxiWjZstdOKlqxFlzQ6WlHQ2R8Sm0g=; b=iJ8OfP+Iv9DyC8P2STVq6EnI7aRmd6/IaeWfFNV8tUH6oB3+/H62nhUWAB8uCPOHSc /AALagFkOvNasS52CAy7/+oTBg+vSe9nSQbqblrHxQJzuo1LHVZlEHiVoQb0JOZK49f2 vEa/xaDVz/z9876vn55Fs/Uip3d9T8kw/BRYc0LKbaqPE9L/bd+p6v5PFeF3Quro+kLj azoip3AlWsFzwo5JYpkczAlKa4si6d0Yls9Hq5BYY8g3GrPu0M7pjl9GlPUlJC/QGdvh AV7GP/+3iF9C/7lmtqtiE5yk3YbMVwPrp71MNuaE9V7OmiyWsqY6zHuo5H5GNolc3cj8 zP7w== X-Gm-Message-State: APjAAAWmS7Tl8U3ZTy5LErzhFM4VidYOTbDG/TvH13bvPANusAUMW6YQ Vm91LLHdpJa1Jsu8uyx1SiU= X-Received: by 2002:a17:902:8a8e:: with SMTP id p14mr45705255plo.28.1582466888756; Sun, 23 Feb 2020 06:08:08 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id v8sm9132919pfn.172.2020.02.23.06.08.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Feb 2020 06:08:07 -0800 (PST) Subject: Re: [PATCH 3/3] watchdog: imx2_wdt: Remove unused include of init.h To: Anson Huang Cc: "wim@linux-watchdog.org" , "shawnguo@kernel.org" , "s.hauer@pengutronix.de" , "kernel@pengutronix.de" , "festevam@gmail.com" , "linux-watchdog@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , dl-linux-imx References: <1582250430-8872-1-git-send-email-Anson.Huang@nxp.com> <1582250430-8872-3-git-send-email-Anson.Huang@nxp.com> <20200222160218.GA12740@roeck-us.net> From: Guenter Roeck Message-ID: Date: Sun, 23 Feb 2020 06:08:06 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/22/20 4:16 PM, Anson Huang wrote: > Hi, Guenter > >> Subject: Re: [PATCH 3/3] watchdog: imx2_wdt: Remove unused include of >> init.h >> >> On Fri, Feb 21, 2020 at 10:00:30AM +0800, Anson Huang wrote: >>> There is nothing in use from init.h, remove it. >>> >> >> NACK, sorry; this driver uses __init and __exit_p. > > Ah, yes, just notice them. But I don't understand why the .probe callback needs > __init and .remove callback needs __exit_p? Should they need to be removed? > That is not a matter of "needs". __init causes the code to be removed after initialization. This is ok and desirable if it is known that the hardware is built-in and will only ever be probed once. exit_p causes the code to be removed if it is built into the kernel. This is desirable and makes sense if the device is known to never be removed. Having said that, what _is_ unnecessary is the remove function. Registration could use devm_watchdog_register_device(), and the watchdog subsystem should prevent removal if the watchdog is running. Plus, the removal function is buggy: It doesn' call clk_disable_unprepare() (but that could be handled with devm_add_action_or_reset() in the probe function). In my opinion, fixing all that would be more valuable than trying to drop an include file. Thanks, Guenter