From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964990AbdAKR2m (ORCPT ); Wed, 11 Jan 2017 12:28:42 -0500 Received: from bh-25.webhostbox.net ([208.91.199.152]:33191 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762860AbdAKR2k (ORCPT ); Wed, 11 Jan 2017 12:28:40 -0500 Date: Wed, 11 Jan 2017 09:28:37 -0800 From: Guenter Roeck To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Cc: Marc Gonzalez , Wim Van Sebroeck , linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Mans Rullgard , Thibaud Cornic , Mark Rutland , Arnd Bergmann Subject: Re: [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions Message-ID: <20170111172837.GA22289@roeck-us.net> References: <1484091325-9199-1-git-send-email-linux@roeck-us.net> <1484100561-17638-1-git-send-email-linux@roeck-us.net> <1484100561-17638-5-git-send-email-linux@roeck-us.net> <94c4d5c0-f639-eab1-6706-335977690e88@roeck-us.net> <20170111143917.hedhyfu6m5dopag7@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170111143917.hedhyfu6m5dopag7@pengutronix.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 11, 2017 at 03:39:17PM +0100, Uwe Kleine-König wrote: > On Wed, Jan 11, 2017 at 01:31:47PM +0100, Marc Gonzalez wrote: > > On 11/01/2017 11:52, Guenter Roeck wrote: > > > > > On 01/11/2017 01:07 AM, Marc Gonzalez wrote: > > > > > >>> @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device *pdev) > > >>> err = clk_prepare_enable(dev->clk); > > >>> if (err) > > >>> return err; > > >>> + err = devm_add_action_or_reset(&pdev->dev, > > >>> + (void(*)(void *))clk_disable_unprepare, > > >>> + dev->clk); > > >>> + if (err) > > >>> + return err; > > This looks wrong. There is no clk_unprepare_disable when > devm_add_action_or_reset fails. > That is what the _or_reset part of devm_add_action_or_reset() is for. > > >> > > >> Hello Guenter, > > >> > > >> I would rather avoid the function pointer cast. > > >> How about defining an auxiliary function for the cleanup action? > > >> > > >> clk_disable_unprepare() is static inline, so gcc will have to > > >> define an auxiliary function either way. What do you think? > > > > > > Not really. It would just make it more complicated to replace the > > > call with devm_clk_prepare_enable(), should it ever find its way > > > into the light of day. > > > > More complicated, because the cleanup function will have to be deleted later? > > The compiler will warn if someone forgets to do that. > > > > In my opinion, it's not a good idea to rely on the fact that casting > > void(*)(struct clk *clk) to void(*)(void *) is likely to work as expected > > on most platforms. (It has undefined behavior, strictly speaking.) > > I would expect it to work on all (Linux) platforms. Anyhow, I wonder if > there couldn't be found a better solution. > > If in the end it looks like the following that would be good I think: > > clk = devm_clk_get(...); > if (IS_ERR(clk)) > ... > > ret = devm_clk_prepare_enable(clk) > if (ret) > return ret; > Yes, Dmitry tried to introduce devm_clk_prepare_enable() some 5 years ago, but the effort stalled. My take is that it will be easy to write another coccinelle script to convert to devm_clk_prepare_enable() once that is available, but I didn't see the point of waiting for that, especially since it may never happen. Guenter