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 16:09:05 +0200
From:   Marc Gonzalez <>
To:     Guenter Roeck <>,
        Wim Van Sebroeck <>
Cc:     LKML <>,
        Mans Rullgard <>,
        Dmitry Torokhov <>
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
>>> - 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? :-(
> 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.


Powered by blists - more mailing lists