Received-SPF: pass (google.com: domain of linux-kernel+bounces-124451-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <31ae4628-037a-4ccf-87d5-4cf00ae9c21e@ancud.ru>
Date: Fri, 29 Mar 2024 14:51:18 +0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH net-next v2] tg3: Remove residual error handling in
 tg3_suspend
To: Jakub Kicinski <kuba@kernel.org>
Cc: Michael Chan <mchan@broadcom.com>,
 Pavan Chebbi <pavan.chebbi@broadcom.com>,
 "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>,
 Paolo Abeni <pabeni@redhat.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
 lvc-project@linuxtesting.org, Michael Chan <michael.chan@broadcom.com>
References: <CACKFLikPmtbkvVFerB0WNvLN3w=ia_vd6fUAo8iWpAqNsegMaQ@mail.gmail.com>
 <20240326183544.488242-1-kiryushin@ancud.ru>
 <20240328181020.1bc21a3c@kernel.org>
Content-Language: en-US
From: Nikita Kiryushin <kiryushin@ancud.ru>
In-Reply-To: <20240328181020.1bc21a3c@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Thank you for the feedback!

> Please stop adding these lines, they are unless.
> If you want to attribute the work to some project / employer
> add (SVACE) to your author lines.
>
Tool used signature line (the SVACE one) in that format was put in the
patch as required by lvc-project protocols. I guess, it is used for some
automation by the project, but I can agree, that the needs of some
specific project should not add cruft to the general code base/version control.

Thank you for expressing annoyance about it, I hope it will trigger conversation
about better way of adding the needed information for further iterations of the
project (as this thread is being mirrored to the project mailing list).
> How is deleting dead code a fix?
Originally, that was intended as a fix of a potential problematic case, that
tg3_power_down_prepare() could change in the future, returning a
non-zero status (which would make the removed code not dead, but undead).
But than, as patch evolved, it became a straight up dead code removal.
Probably, I should have removed the "fixes" line at that point, but
I think it still useful as a reference point to know, after which commit this patch
becomes relevant (to know, if it should be back-ported to some version or not,
for example).As I guess from the guide, patches "Fixes:" tag has some special treatment in the development cycle, but what would be more appropriate in that case?
> Hopefully you can find in there whether we suggest posting new versions
> in reply to the old ones..
Thank you for pointing this out! Missed the part about "The new version of
patches should be posted as a separate thread, not as a reply to the
previous posting. Change log should include a link to the previous posting"
while reading netdev guide.

Should I resubmit the patch in the separate thread now? If so, should I
make any changes to it (as discussed)? Would it bump the patch version
(the patch would essentially be the same, as only some metadata like
change log itself would change)?