Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Guenter Roeck <groeck7@gmail.com>
Message-ID: <4e2750a0-3ad5-f3d9-1d23-82d89f592476@roeck-us.net>
Date:   Wed, 7 Sep 2022 08:57:40 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH v4 01/21] hwmon: (mr75203) fix coding style space errors
Content-Language: en-US
To:     Andy Shevchenko <andriy.shevchenko@intel.com>,
        "Farber, Eliav" <farbere@amazon.com>
Cc:     jdelvare@suse.com, robh+dt@kernel.org, p.zabel@pengutronix.de,
        rtanwar@maxlinear.com, linux-hwmon@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        hhhawa@amazon.com, jonnyc@amazon.com
References: <20220906083356.21067-1-farbere@amazon.com>
 <20220906083356.21067-2-farbere@amazon.com>
 <20220906165229.GA594012@roeck-us.net>
 <9323b609-cb9d-8b3d-2894-65296487cdb1@amazon.com>
 <Yxit2fq1kwzIN9x0@smile.fi.intel.com>
From:   Guenter Roeck <linux@roeck-us.net>
In-Reply-To: <Yxit2fq1kwzIN9x0@smile.fi.intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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