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
| ||
|
Message-ID: <c875ddd9-13f4-c6d4-4537-21b80000b9b5@roeck-us.net> 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
Powered by blists - more mailing lists