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]

Date:   Wed, 7 Sep 2022 17:42:33 +0300
From:   Andy Shevchenko <andriy.shevchenko@...el.com>
To:     "Farber, Eliav" <farbere@...zon.com>
Cc:     Guenter Roeck <linux@...ck-us.net>, 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 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.

-- 
With Best Regards,
Andy Shevchenko