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;
Message-ID: <1aadcc20-4ee7-af56-36db-1d036c7747c5@arinc9.com>
Date:   Wed, 29 Mar 2023 00:26:46 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [PATCH net 4/7] net: dsa: mt7530: set both CPU port interfaces to
 PHY_INTERFACE_MODE_NA
Content-Language: en-US
To:     Vladimir Oltean <olteanv@gmail.com>
Cc:     Sean Wang <sean.wang@mediatek.com>,
        Landen Chao <Landen.Chao@mediatek.com>,
        DENG Qingfang <dqfext@gmail.com>, Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>,
        Russell King <linux@armlinux.org.uk>,
        =?UTF-8?Q?Ren=c3=a9_van_Dorst?= <opensource@vdorst.com>,
        Russell King <rmk+kernel@armlinux.org.uk>,
        Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>,
        Richard van Schagen <richard@routerhints.com>,
        Richard van Schagen <vschagen@cs.com>,
        Frank Wunderlich <frank-w@public-files.de>,
        erkin.bozoglu@xeront.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org
References: <20230326140818.246575-1-arinc.unal@arinc9.com>
 <20230326140818.246575-5-arinc.unal@arinc9.com>
 <20230327191242.4qabzrn3vtx3l2a7@skbuf>
 <8450084e-1474-17fa-32c2-a4653b74ff17@arinc9.com>
 <20230328112002.2p7r6estix3dpijm@skbuf>
From:   =?UTF-8?B?QXLEsW7DpyDDnE5BTA==?= <arinc.unal@arinc9.com>
In-Reply-To: <20230328112002.2p7r6estix3dpijm@skbuf>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 28/03/2023 14:20, Vladimir Oltean wrote:
> On Tue, Mar 28, 2023 at 12:57:57AM +0300, Arınç ÜNAL wrote:
>> I don't appreciate your consistent use of the word "abuse" on my patches.
> 
> Consistent would mean that, when given the same kind of input, I respond
> with the same kind of output. I'm thinking you'd want a reviewer to do that?

Of course.

> 
> Last time I said: "It's best not to abuse the net.git tree with non-bugfix patches."
> https://patchwork.kernel.org/project/netdevbpf/patch/20230307220328.11186-1-arinc.unal@arinc9.com/
> 
> If anything, Jakub was/is slightly inconsistent by accepting those previous
> non-bugfix patches to the net.git tree, and then agreeing with me. He probably
> did that thinking it wasn't a hill worth dying on, which I can agree with.
> But I'm afraid that this didn't help you realize that yes, maybe you really
> are abusing the process by submitting exclusively non-bugfix commits to the
> net tree. There's a fine balance between trying to be nice and trying not to
> transmit the wrong message.
> 
> It would be good if you could clarify your objection regarding my consistent
> use of the word "abuse" on your patches.
> 
> There is a document at Documentation/process/stable-kernel-rules.rst
> which I remember having shared with you before, where there are some
> indications as to what constitutes a legitimate candidate for "stable"
> and what does not.

I forgot this existed, sorry about that. I had this thought left in my 
mind that "any changes that are not new features must go to the net 
tree", which clearly is not the case. I see what you mean now. None of 
my patches on the series satisfy all of the rules specified on the document.

I just think your response could've been less harsh considering I didn't 
intentionally do this. Anyway, it's all resolved now so let's not drag 
this further.

> 
>> I'm by no means a senior C programmer. I'm doing my best to correct the
>> driver.
>>
>> Thank you for explaining the process of phylink with DSA, I will adjust my
>> patches accordingly.
>>
>> I suggest you don't take my patches seriously for a while, until I know
>> better.
> 
> Whether you're a junior or a senior C programmer is entirely irrelevant
> here. I have no choice but to take your patches seriously unless otherwise
> specified, in the commit message, cover letter, or by marking them as
> RFC/RFT (but even then, their intention must be very clearly specified,
> so that I know what to comment on, or test).
> 
> I don't think you really want what you're asking for, which is for
> people to not take your patches seriously. I recommend forming a smaller
> community of people which does preliminary patch review and discusses
> issues around the hardware you're working on, prior to upstream submission.
> That would, at least, be more productive.

Yes, of course. I'm actually planning something similar that involves 
OpenWrt, thanks.

Arınç