[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <MWHPR11MB1693FA23D320DC2DE585C696EF149@MWHPR11MB1693.namprd11.prod.outlook.com>
Date: Thu, 1 Dec 2022 15:56:47 +0000
From: <Jerry.Ray@...rochip.com>
To: <olteanv@...il.com>
CC: <kuba@...nel.org>, <andrew@...n.ch>, <f.fainelli@...il.com>,
<davem@...emloft.net>, <edumazet@...gle.com>, <pabeni@...hat.com>,
<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next v3] dsa: lan9303: Add 3 ethtool stats
>> Won't be able to get to stats64 this cycle. Looking to migrate to phylink
>> first. This is a pretty old driver.
>>
>> Understand you don't know me - yet.
>
>It would be good if you first prepared a bug fix patch for the existing
>kernel stack memory leakage, and submit that to the net.git tree.
>The net.git is merged back into net-next.git every ~Thursday, and
>generally speaking, either you wait for bug fixes to land back into
>net-next before you submit new net-next material in the same areas,
>or the netdev and linux-next maintainers will have to resolve the merge
>conflict between trees manually. Not a huge deal, but it is kind of a
>nuisance for backports (to not be able to linearize a series of cherry
>picks) and all in all, it's best to organize your work such that you
>don't conflict with yourself.
>
I'm unaware of a kernel stack memory leak. Can you point me to a thread?
As for splitting bug fix patches, ...
A comment was made against my patch and I looked to make things consistent
with the existing code. I failed to see the distinction of addressing the
issue with the patch and addressing the same issue with existing code.
Thanks for explaining the reasoning behind why separating the patches
matters. I'll try to keep that in mind for future submissions.
Regards,
Jerry.
Powered by blists - more mailing lists