[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6f8ec860-42ff-d33a-9a58-626d2fa4e7c8@free.fr>
Date: Wed, 10 Apr 2019 16:09:05 +0200
From: Marc Gonzalez <marc.w.gonzalez@...e.fr>
To: Guenter Roeck <linux@...ck-us.net>,
Wim Van Sebroeck <wim@...ux-watchdog.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Mans Rullgard <mans@...sr.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH 23/23] watchdog: tangox_wdt: Convert to use device managed
functions and other improvements
On 10/04/2019 15:37, Guenter Roeck wrote:
> On 4/10/19 6:04 AM, Marc Gonzalez wrote:
>
>> On 09/04/2019 19:24, Guenter Roeck wrote:
>>
>>> Use device managed functions to simplify error handling, reduce
>>> source code size, improve readability, and reduce the likelihood of bugs.
>>> Other improvements as listed below.
>>>
>>> The conversion was done automatically with coccinelle using the
>>> following semantic patches. The semantic patches and the scripts
>>> used to generate this commit log are available at
>>> https://github.com/groeck/coccinelle-patches
>>>
>>> - Drop assignments to otherwise unused variables
>>> - Drop unnecessary braces around conditional return statements
>>> - Drop empty remove function
>>> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare
>>> - Replace stop on remove with call to watchdog_stop_on_unregister()
>>> - Use devm_watchdog_register_driver() to register watchdog device
>>
>> No devm_clk_prepare() in mainline? :-(
>>
>> https://lore.kernel.org/patchwork/patch/755487/
>
> We went through that several times and never succeeded. This was the major
> reason why I didn't submit this series earlier since I was hoping for it
> to appear at some point. Unfortunately, someone always objected, typically
> with comments along the line that it could be misused, or citing individual
> examples where the current code in some driver is wrong and should be fixed
> instead.
>
> This isn't really a technical argument: Everything can be misused, and all
> code has bugs. Neither is a reason to reject a new useful API. As such, one
> has to assume that after refuting such arguments, and even after fixing all
> bugs in existing code, the opponents of the new API will come up with other
> reasons to reject it.
>
> At the end, I gave up trying. Feel free to try yourself; I most definitely
> won't try it anymore. Using devm_add_action_or_reset() is a bit more clumsy,
> but works just as well.
Hello Guenter,
I am saddened to read about your frustration. I might give it a try, if Dmitry
doesn't feel like giving it another shot.
Regards.
Powered by blists - more mailing lists