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:   Sat, 20 Jan 2018 07:50:47 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>,
        Paul Cercueil <paul@...pouillou.net>
Cc:     Ralf Baechle <ralf@...ux-mips.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Wim Van Sebroeck <wim@...ana.be>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux-MIPS <linux-mips@...ux-mips.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-watchdog@...r.kernel.org
Subject: Re: [PATCH v2 4/8] watchdog: JZ4740: Drop module remove function

On 01/19/2018 11:41 PM, PrasannaKumar Muralidharan wrote:
> Hi Paul,
> 
> On 30 December 2017 at 19:21, Paul Cercueil <paul@...pouillou.net> wrote:
>> When the watchdog was configured for nowayout, and after the
>> userspace watchdog daemon closed the dev node without sending the
>> magic character, unloading this module stopped the watchdog
>> hardware, which was clearly a problem.
>>
>> Besides, unloading the module is not possible when the userspace
>> watchdog daemon is running, so it's safe to assume that we don't
>> need to stop the watchdog hardware in the jz4740_wdt_remove()
>> function.
>>
>> For this reason, the jz4740_wdt_remove() function can then be
>> dropped alltogether.
>>
>> Signed-off-by: Paul Cercueil <paul@...pouillou.net>
>> ---
>>   drivers/watchdog/jz4740_wdt.c | 8 --------
>>   1 file changed, 8 deletions(-)
>>
>>   v2: New patch in this series
>>
>> diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
>> index fa7f49a3212c..02b9b8e946a2 100644
>> --- a/drivers/watchdog/jz4740_wdt.c
>> +++ b/drivers/watchdog/jz4740_wdt.c
>> @@ -205,16 +205,8 @@ static int jz4740_wdt_probe(struct platform_device *pdev)
>>          return 0;
>>   }
>>
>> -static int jz4740_wdt_remove(struct platform_device *pdev)
>> -{
>> -       struct jz4740_wdt_drvdata *drvdata = platform_get_drvdata(pdev);
>> -
>> -       return jz4740_wdt_stop(&drvdata->wdt);
>> -}
>> -
>>   static struct platform_driver jz4740_wdt_driver = {
>>          .probe = jz4740_wdt_probe,
>> -       .remove = jz4740_wdt_remove,
>>          .driver = {
>>                  .name = "jz4740-wdt",
>>                  .of_match_table = of_match_ptr(jz4740_wdt_of_matches),
>> --
>> 2.11.0
>>
>>
> 
> As ".remove" is removed and wdt is required for restarting the system
> I am thinking that stop callback is also not required. If so does it
> makes sense to remove the stop callback? I can submit a patch for the
> same once this patch series goes in.
> 
The remove function was removed because it would otherwise be an empty
function. Since it is optional, it can and should be removed if it does not
do anything. If the stop function is removed, it is no longer possible
to stop the watchdog. Why would this make sense, and why would it make sense
to drop the stop function if there is no remove function ?

Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ