[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230222232112.v7gokdmr34ii2lgt@skbuf>
Date: Thu, 23 Feb 2023 01:21:12 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Marek Vasut <marex@...x.de>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Andrew Lunn <andrew@...n.ch>,
Arun Ramadoss <arun.ramadoss@...rochip.com>,
Eric Dumazet <edumazet@...gle.com>,
Florian Fainelli <f.fainelli@...il.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Russell King <linux@...linux.org.uk>,
UNGLinuxDriver@...rochip.com,
Woojung Huh <woojung.huh@...rochip.com>, stable@...r.kernel.org
Subject: Re: [PATCH] net: dsa: microchip: Fix gigabit set and get function
for KSZ87xx
On Wed, Feb 22, 2023 at 11:58:23PM +0100, Marek Vasut wrote:
> On 2/22/23 23:31, Vladimir Oltean wrote:
> > On Wed, Feb 22, 2023 at 11:05:10PM +0100, Marek Vasut wrote:
> > > OK, to make this simple, can you write a commit message which you consider
> > > acceptable, to close this discussion ?
> >
> > Nope. The thing is, I'm sure you can, too. Maybe you need to take a
> > break and think about this some more.
>
> Sorry, not like this and not with this feedback tone.
>
> If Arun wants to send V2 to fix the actual bug, fine by me.
I don't see what is wrong with this feedback tone, but if you could tell me,
I will make an effort to think about it and see what I can do to change it.
On the other hand, I will not write the commit message for you and that's
not negotiable, because from the replies to me and to Russell, I get the
suspicion that there's some sort of hidden intention for this to be used
against me somehow, and I really have nothing else to base my judgement
on, than your hint that there is a bug there, and the code. But the
driver might behave in much more subtle ways which I may be completely
missing, and I may think that I'm fixing something when I'm not. I have
no way to know that except by booting a board, which I do not have (but
you do). For example, I don't even know which KSZ8 boards rely on pin
strapping and which ones do really need the configuration to be done by
Linux. I'm completely blind, and the refusal to tell you what to write
word by word is a self defense mechanism.
It's good that you gave Arun permission to take your patch, test it on a
KSZ8 (which seems like something he wasn't doing that often during
refactoring), give it an accurate description of the problem, and
resubmit it while keeping your authorship. Arun is an active contributor
and reviewer on the KSZ driver and there's a good chance he might actually
even do it. This is good not because you gave up (IMO for an unjustified
reason, but maybe that's just my perspective), but because there still
is a path forward for the actual bug to get fixed.
Powered by blists - more mailing lists