linux-kernel - Re: [PATCH v4 01/21] hwmon: (mr75203) fix coding style space errors

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: <4e2750a0-3ad5-f3d9-1d23-82d89f592476@roeck-us.net>
Date:   Wed, 7 Sep 2022 08:57:40 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Andy Shevchenko <andriy.shevchenko@...el.com>,
        "Farber, Eliav" <farbere@...zon.com>
Cc:     jdelvare@...e.com, robh+dt@...nel.org, p.zabel@...gutronix.de,
        rtanwar@...linear.com, linux-hwmon@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        hhhawa@...zon.com, jonnyc@...zon.com
Subject: Re: [PATCH v4 01/21] hwmon: (mr75203) fix coding style space errors

On 9/7/22 07:42, Andy Shevchenko wrote:
> On Wed, Sep 07, 2022 at 09:50:00AM +0300, Farber, Eliav wrote:
>> On 9/6/2022 7:52 PM, Guenter Roeck wrote:
>>> On Tue, Sep 06, 2022 at 08:33:36AM +0000, Eliav Farber wrote:
>>>> Fix: "ERROR: space required before the open parenthesis '('"
>>>>
>>>> Fixes: 9d823351a337 ("hwmon: Add hardware monitoring driver for
>>>> Moortec MR75203 PVT controller")
>>>
>>> Coding style "fixes" do not fix the code. I consider using the Fixes: tag
>>> for those to close to an abuse of that tag (and it would be great if that
>>> was spelled out somewhere). As it is, I can not with good conscience
>>> apply
>>> this patch to the mainline kernel (especially not for -rc5), meaning the
>>> entire series will have to wait for the next release window unless there
>>> are no conflicts.
>> Because as you mentioned  it is not a functional fix in the code I’ll
>> remove the Fixes tag in v5.
>> I checked older kernel versions and patch applies without conflicts.
>> That’s also why I moved it to be first in the series, so it will be
>> before any of my other changes that night cause merge problems for
>> other branches.
> 
> If it's not a fix, it should go _after_ real fixes.
> And by nature this kind of patch is usually at the end of the series.
> 

I don't care where it is, really, as long as it is after the real fixes.
And obviously I would not want to see a patch fixing something introduced
in a previous patch of the same series.

Thanks,
Guenter