linux-kernel - Re: [PATCH v4] hwmon: (asus-ec-sensors) merge setup functions

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]

Message-ID: <7f3fc06f-cf4e-2dc6-e68a-917117fe8895@roeck-us.net>
Date:   Wed, 16 Feb 2022 10:49:56 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Eugene Shalygin <eugene.shalygin@...il.com>
Cc:     Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] hwmon: (asus-ec-sensors) merge setup functions

On 2/16/22 10:23, Eugene Shalygin wrote:
> On Wed, 16 Feb 2022 at 19:08, Guenter Roeck <linux@...ck-us.net> wrote:
>> $ scripts/checkpatch.pl --strict asus-ec
> 
> So, contributors have to use the --strict option?
> 
>> WARNING: braces {} are not necessary for single statement blocks
> 
> The file is full of such braces, because I like them and it is only a
> warning. How should I proceed with them?
> 

Warnings are also seen without --strict; that only adds the CHECK messages.
You should follow Linux kernel coding style when you write kernel code,
not your personal preferences. Also please consider reading
Documentation/hwmon/submitting-patches.rst, which specifically says

* Please run your patch through 'checkpatch --strict'. There should be no
   errors, no warnings, and few if any check messages. If there are any
   messages, please be prepared to explain.

* If your patch generates checkpatch errors, warnings, or check messages,
   please refrain from explanations such as "I prefer that coding style".
   Keep in mind that each unnecessary message helps hiding a real problem,
   and a consistent coding style makes it easier for others to understand
   and review the code.

Thanks,
Guenter