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: <Yxit2fq1kwzIN9x0@smile.fi.intel.com>
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ