From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937513AbdAKP2c (ORCPT ); Wed, 11 Jan 2017 10:28:32 -0500 Received: from mail1.bemta12.messagelabs.com ([216.82.251.8]:41472 "EHLO mail1.bemta12.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937077AbdAKP2T (ORCPT ); Wed, 11 Jan 2017 10:28:19 -0500 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileJIrShJLcpLzFFi42I5fN1ilS6/f1m Ewc3V5hZ/Jx1jt9j0+BqrxeVdc9gsbqzbx27xZOEZJosfD6czWSy9fpHJ4vbEyYwWt2a8YHXg 9Fgzbw2jx+9fkxg9rm0W89i8pN7jzelT7B79fw08dn5vYPf4vEkugCOKNTMvKb8igTXj8gr1g q3iFQcbJ7I2MPYLdzFycQgJLGOUONq9jqmLkZNDWCBS4sHSOewgtoiAmkTzqRY2kCJmgdtMEo ufLmSB6OhllnjY/A+sg03AROLm/XMsIDavgLPE0j0nwLpZBFQl9t/4DhYXFUiQWHFuDhNEjaD EyZlPwOKcAg4SaxevZwaxmQU0JVq3/2aHsAUllrxewwhhy0tsfzsHrEZIQFvi/cbFrCC2hICC xNTJrcwTGAVmIRk7C8moWUhGzUIyagEjyypGjeLUorLUIl1DM72kosz0jJLcxMwcXUNDI73c1 OLixPTUnMSkYr3k/NxNjMA4qmdgYNzB2Djd6xCjJAeTkijvPdeyCCG+pPyUyozE4oz4otKc1O JDjDIcHEoSvKd9gXKCRanpqRVpmTnAiIZJS3DwKInwuoCkeYsLEnOLM9MhUqcYFaXEeReCJAR AEhmleXBtsCRyiVFWSpiXkYGBQYinILUoN7MEVf4VozgHo5Iw7wWQKTyZeSVw018BLWYCWhxp VwyyuCQRISXVwChxaVf+4RVTvwhdeuVt8+iCg3c169YDtXIRe4+mhjzR2lg09dtDIYeuJylFf rJa9tKnb6/buiVsT3EBn49RsoA7x5X6Mvlg9aXcwr9c0pj0CtqnLnjIFH8ohEdl0fVbCctOGV 3Vdvtc9XZ93PFZz0q2NwuVasSfWxWV8rFBauHl+ittISJll5RYijMSDbWYi4oTAVjR42UdAwA A X-Env-Sender: Marc_Gonzalez@sigmadesigns.com X-Msg-Ref: server-13.tower-163.messagelabs.com!1484148494!106426831!1 X-Originating-IP: [195.215.56.170] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Subject: Re: [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions To: Guenter Roeck CC: Wim Van Sebroeck , , , , Mans Rullgard , Thibaud Cornic , Mark Rutland , Uwe Kleine-Konig , Arnd Bergmann 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> From: Marc Gonzalez Message-ID: Date: Wed, 11 Jan 2017 16:28:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 SeaMonkey/2.47 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Language: Content-Transfer-Encoding: 7bit X-Originating-IP: [172.27.0.114] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/01/2017 15:25, Guenter Roeck wrote: > On 01/11/2017 04:31 AM, 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; >>>> >>>> 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 do hear that you object to this code. > > However, I must admit that you completely lost me here. It is a cast from > one function pointer to another, Perhaps you are used to work at the assembly level, where pointers are just addresses, and all pointers are interchangeable. At a slightly higher level (C abstract machine), it is not so. > passed as argument to another function, > with a secondary cast of its argument from a typed pointer to a void pointer. > I don't think C permits for "undefined behavior, strictly speaking". The C standard leaves quite a lot of behavior undefined, e.g. char *foo = "hello"; foo[1] = 'a'; // UB char buf[4]; *(int *)&buf = 0xdeadbeef; // UB 1 << 64; // UB > Besides, that same mechanism is already used elsewhere, which is how I > got the idea. Are you claiming that there are situations where it won't > work ? If this technique is already used elsewhere in the kernel, then I'll crawl back under my rock (and weep). I can see two issues with the code you propose. First is the same for all casts: silencing potential warnings, e.g. if the prototype of clk_disable_unprepare ever changed. (Though casts are required for vararg function arguments.) Second is just theory and not a real-world concern. >> Do you really dislike the portable solution I suggested? :-( > > It is not more portable than the above. It is more expensive and adds more > code. Maybe I am mistaken. Can you tell me why adding an auxiliary function is more expensive? (In CPU cycles?) clk_disable_unprepare() is static inline, so an auxiliary function exists either way (implicit or explicit). Regards. From mboxrd@z Thu Jan 1 00:00:00 1970 From: marc_gonzalez@sigmadesigns.com (Marc Gonzalez) Date: Wed, 11 Jan 2017 16:28:12 +0100 Subject: [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions In-Reply-To: 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> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 11/01/2017 15:25, Guenter Roeck wrote: > On 01/11/2017 04:31 AM, 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; >>>> >>>> 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 do hear that you object to this code. > > However, I must admit that you completely lost me here. It is a cast from > one function pointer to another, Perhaps you are used to work at the assembly level, where pointers are just addresses, and all pointers are interchangeable. At a slightly higher level (C abstract machine), it is not so. > passed as argument to another function, > with a secondary cast of its argument from a typed pointer to a void pointer. > I don't think C permits for "undefined behavior, strictly speaking". The C standard leaves quite a lot of behavior undefined, e.g. char *foo = "hello"; foo[1] = 'a'; // UB char buf[4]; *(int *)&buf = 0xdeadbeef; // UB 1 << 64; // UB > Besides, that same mechanism is already used elsewhere, which is how I > got the idea. Are you claiming that there are situations where it won't > work ? If this technique is already used elsewhere in the kernel, then I'll crawl back under my rock (and weep). I can see two issues with the code you propose. First is the same for all casts: silencing potential warnings, e.g. if the prototype of clk_disable_unprepare ever changed. (Though casts are required for vararg function arguments.) Second is just theory and not a real-world concern. >> Do you really dislike the portable solution I suggested? :-( > > It is not more portable than the above. It is more expensive and adds more > code. Maybe I am mistaken. Can you tell me why adding an auxiliary function is more expensive? (In CPU cycles?) clk_disable_unprepare() is static inline, so an auxiliary function exists either way (implicit or explicit). Regards.