linux-kernel - Re: [PATCH 23/23] watchdog: tangox_wdt: Convert to use device managed functions and other improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Apr 2019 06:37:21 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Marc Gonzalez <marc.w.gonzalez@...e.fr>,
        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 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 likelyhood 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.

Guenter