From: "Arınç ÜNAL" <arinc.unal@arinc9.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: "Andrew Lunn" <andrew@lunn.ch>,
"Ilya Lipnitskiy" <ilya.lipnitskiy@gmail.com>,
"René van Dorst" <opensource@vdorst.com>,
"Eric Dumazet" <edumazet@google.com>,
erkin.bozoglu@xeront.com,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Russell King" <linux@armlinux.org.uk>,
"Richard van Schagen" <richard@routerhints.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Landen Chao" <Landen.Chao@mediatek.com>,
"Richard van Schagen" <vschagen@cs.com>,
"Sean Wang" <sean.wang@mediatek.com>,
"DENG Qingfang" <dqfext@gmail.com>,
"Russell King" <rmk+kernel@armlinux.org.uk>,
linux-mediatek@lists.infradead.org,
"Matthias Brugger" <matthias.bgg@gmail.com>,
linux-arm-kernel@lists.infradead.org,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net 4/7] net: dsa: mt7530: set both CPU port interfaces to PHY_INTERFACE_MODE_NA
Date: Wed, 29 Mar 2023 00:26:46 +0300 [thread overview]
Message-ID: <1aadcc20-4ee7-af56-36db-1d036c7747c5@arinc9.com> (raw)
In-Reply-To: <20230328112002.2p7r6estix3dpijm@skbuf>
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ç
next prev parent reply other threads:[~2023-03-28 21:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-26 14:08 [PATCH 0/7] net: dsa: mt7530: fix port 5 phylink, phy muxing, and port 6 arinc9.unal
2023-03-26 14:08 ` [PATCH net 1/7] net: dsa: mt7530: fix comments regarding port 5 and 6 for both switches arinc9.unal
2023-03-26 14:08 ` [PATCH net 2/7] net: dsa: mt7530: fix phylink for port 5 and fix port 5 modes arinc9.unal
2023-03-27 18:49 ` Vladimir Oltean
2023-03-27 21:44 ` Arınç ÜNAL
2023-03-26 14:08 ` [PATCH net 3/7] net: dsa: mt7530: do not run mt7530_setup_port5() if port 5 is disabled arinc9.unal
2023-03-27 18:56 ` Vladimir Oltean
2023-03-27 21:46 ` Arınç ÜNAL
2023-03-26 14:08 ` [PATCH net 4/7] net: dsa: mt7530: set both CPU port interfaces to PHY_INTERFACE_MODE_NA arinc9.unal
2023-03-27 19:12 ` Vladimir Oltean
2023-03-27 21:57 ` Arınç ÜNAL
2023-03-28 2:03 ` Jakub Kicinski
2023-03-28 11:20 ` Vladimir Oltean
2023-03-28 21:26 ` Arınç ÜNAL [this message]
2023-03-26 14:08 ` [PATCH net 5/7] net: dsa: mt7530: set up port 5 before CPU ports are enabled arinc9.unal
2023-03-26 14:08 ` [PATCH net 6/7] net: dsa: mt7530: call port 6 setup from mt7530_mac_config() arinc9.unal
2023-03-26 14:08 ` [PATCH net 7/7] net: dsa: mt7530: remove pad_setup function pointer arinc9.unal
2023-03-28 11:21 ` [PATCH 0/7] net: dsa: mt7530: fix port 5 phylink, phy muxing, and port 6 Vladimir Oltean
2023-03-28 21:27 ` Arınç ÜNAL
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1aadcc20-4ee7-af56-36db-1d036c7747c5@arinc9.com \
--to=arinc.unal@arinc9.com \
--cc=Landen.Chao@mediatek.com \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=erkin.bozoglu@xeront.com \
--cc=f.fainelli@gmail.com \
--cc=ilya.lipnitskiy@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=opensource@vdorst.com \
--cc=pabeni@redhat.com \
--cc=richard@routerhints.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=sean.wang@mediatek.com \
--cc=vschagen@cs.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox