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: <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