Re: [PATCH net 4/7] net: dsa: mt7530: set both CPU port interfaces to PHY_INTERFACE_MODE_NA

[Vladimir Oltean]

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?

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@xxxxxxxxxx/

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'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.