[PATCH net-next 0/6] net: dsa: always use phylink

[Vladimir Oltean]

On Mon, Jul 18, 2022 at 09:53:23AM +0100, Russell King (Oracle) wrote:
> On Sat, Jul 16, 2022 at 04:13:45PM +0300, Vladimir Oltean wrote:
> > On Sat, Jul 16, 2022 at 12:43:00PM +0100, Russell King (Oracle) wrote:
> > > In the first RFC series I sent on the 24 June, I explicitly asked the
> > > following questions:
> > (...)
> > > I even stated: "Please look at the patches and make suggestions on how
> > > we can proceed to clean up this quirk of DSA." and made no mention of
> > > wanting something explicitly from Andrew.
> > > 
> > > Yet, none of those questions were answered.
> > > 
> > > So no, Jakub's comments are *not* misdirected at all. Go back and read
> > > my June 24th RFC series yourself:
> > > 
> > > https://lore.kernel.org/all/YrWi5oBFn7vR15BH@shell.armlinux.org.uk/
> > 
> > I don't believe I need to justify myself any further for why I didn't
> > leave a comment on any certain day. I left my comments when I believed
> > it was most appropriate for me to intervene (as someone who isn't really
> > affected in any way by the changes, except for generally maintaining
> > what's in net/dsa/, and wanting to keep a clean framework structure).
> > Also, to repeat myself, blaming me for leaving comments, but doing so
> > late, is not really fair. I could have not responded at all, and I
> > wouldn't be having this unpleasant discussion. It begs the question
> > whether you're willing to be held accountable in the same way for the
> > dates on which you respond on RFC patches.
> > 
> > > I've *tried* my best to be kind and collaborative, but I've been
> > > ignored. Now I'm hacked off. This could have been avoided by responding
> > > to my explicit questions sooner, rather than at the -rc6/-rc7 stage of
> > > the show.
> > 
> > I think you should continue to try your best to be kind and collaborative,
> > you weren't provoked or intentionally ignored in any way, and it isn't
> > doing these patches any good.
> 
> And yet again, I don't have answers to many of those questions... which
> just shows how broken this process is, and how utterly pointless it is
> 0to ask any questions in this area.
> 
> My conclusion: you don't care one bit to even answer questions until
> there's a chance that patches that you disagree with might be merged,
> and oh my god, you've got to respond to stop that happening because you
> might disagree with something. You can't do the collaborative thing and
> respond when someone asks explicit questions about how things should be
> done.
> 
> I'm not going to let this go. I'm really pissed off by this and you
> are the focus of my frustration.

The hypothesis that you put forward is that I'm sabotaging you by not
responding to RFCs, then leaving comments when you submit the patches
proper, just so that they're delayed because I don't agree with them;
and that the process is broken because it allows me to do just that and
get away with it (for fun, I assume?).

So first off, you sent the first RFC towards 2 people in To:, and 19
people in Cc:. I was one of the people in Cc. You didn't ask *me* any
explicit question. In fact, when you did, I responded within 5 hours:
https://lore.kernel.org/linux-arm-kernel/20220707154303.236xaeape7isracw@skbuf/

Then, why did I not respond earlier to questions I had an opinion on?

Based on prior experience, anything I reply to you has a chance of
inflaming you for reasons that are outside of my control, and the
discussion derails and eventually ends with you saying that I'm being
difficult and you're quitting for the day, week, month, kernel release
cycle or what not. I'm not saying that's my fault or your fault in
general, it's just a statistical observation based on past interactions,
and it looks like this one is no different.

With regard to this topic, there was ample opportunity for the patch set
to come to a resolve without my intervention, and I decided that the
best way to maximize the chances of this discussion not going sideways
is to not say anything at all, especially when I don't need to.
Gradually, the opportunity for the patch set to resolve itself without
my intervention diminished, and I started offering my feedback to the code.

It's perhaps necessary of me to not let this phrase of yours unaddressed,
because it is subtly part of your argument that I'm just trying to delay
your patches as part of a sabotage plot:

| The only thing that delayed them was your eventual comments about
| re-working how it was being done.

Let's not forget that I did *not* request you to rework the implementation
to use software nodes. I simply went with the code you originally proposed,
explained why it is unnaturally structured in my view, asked you why you
did not consider an alternative structure if you're not willing to make
phylink absorb the logic, then you said you'd be happy to rework using
software nodes.
https://lore.kernel.org/netdev/20220707193753.2j67ni3or3bfkt6k@skbuf/

My feedback was very actionable, I put forward a working prototype for
using software nodes that did consume time for me to write, I was not
being handwavy in any way. More importantly, you agreed with it and are
using it now. And all of that happened during RFC stages. To ignore
these facts when you state that I respond only to non-RFC patches is a
lie by omission. I give feedback to code in the order of importance.
Now was the time to point out that (a) I don't want to add support for
the defaulting mode on CPU ports for drivers that didn't have it
previously, and (b) I'd like to keep the current implementation of the
defaulting feature as "don't register with phylink" as the default, with
just an opt-in to create the software node. Drivers can opt into that
behavior as need shows (breakage reports). Again, this is all extremely
actionable feedback, and rather minor in the grand scheme of things.


So I'm sorry, but your frustration expressed towards me for ignoring RFC
patches *is* misdirected and there's nothing I will consider changing.
If the discussion derailed now due to me it doesn't mean it wouldn't
have derailed earlier. There are still many people who could have said
more things than they did, and yet, I'm not even blaming them for not
doing that. There is a chapter in a book by Robert Cialdini called
"Influence: The Psychology of Persuasion" which discusses social proof,
the mechanism through which people tend to do what others do when
otherwise unsure. I'm paraphrasing, but there is a paragraph discussing
what can be done when social proof works against you, for example you're
being attacked on the street, you ask for help and nobody appears to do
anything except for passing by. Summarized, you should ask for very
specific things, point to people, say names, rather than get frustrated
that the crowd does nothing.

> Well, its now too late to do anything about this. This is going to miss
> this cycle. It might get in next cycle, and whoopy do, for a kernel
> that's very likely to be a LTS. Given the lack of testing that sounds
> like a complete and utter disaster. One that was entirely avoidable had
> feedback been given EARLIER in this cycle.

If your patch set was a silver bullet to avoid breakage, that would have
maybe changed things a little, but it isn't. For any driver that might
boot using a DT blob with the defaulting feature for the CPU port, there
is a gamble to be taken whether the better thing to do is to unleash phylink
at it unattended or to let it be. Obviously having a driver maintainer
assist phylink would be the correct thing, but until the board in question
reaches a maintainer, chances are it will probably reach a user.

What I'm trying to obtain in terms of changes is that the user can at
least correlate the breakage he's seeing with a dmesg warning message
that clearly indicates what phylink or DSA tried to do in lack of clear
DT description.