Message-ID: <c17c272b-d1cb-8f29-5559-fea1f29f2a37@arinc9.com>
Date:   Wed, 15 Mar 2023 12:31:16 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: [PATCH net-next v13 11/16] net: dsa: mt7530: use external PCS
 driver
To:     Vladimir Oltean <vladimir.oltean@nxp.com>
Cc:     Daniel Golle <daniel@makrotopia.org>, netdev@vger.kernel.org,
        linux-mediatek@lists.infradead.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        Russell King <linux@armlinux.org.uk>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Lorenzo Bianconi <lorenzo@kernel.org>,
        Mark Lee <Mark-MC.Lee@mediatek.com>,
        John Crispin <john@phrozen.org>, Felix Fietkau <nbd@nbd.name>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        DENG Qingfang <dqfext@gmail.com>,
        Landen Chao <Landen.Chao@mediatek.com>,
        Sean Wang <sean.wang@mediatek.com>,
        Paolo Abeni <pabeni@redhat.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Eric Dumazet <edumazet@google.com>,
        "David S. Miller" <davem@davemloft.net>,
        Vladimir Oltean <olteanv@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Andrew Lunn <andrew@lunn.ch>,
        =?UTF-8?Q?Bj=c3=b8rn_Mork?= <bjorn@mork.no>,
        Frank Wunderlich <frank-w@public-files.de>,
        Alexander Couzens <lynxis@fe80.eu>
References: <cover.1678357225.git.daniel@makrotopia.org>
 <2ac2ee40d3b0e705461b50613fda6a7edfdbc4b3.1678357225.git.daniel@makrotopia.org>
 <e99cc7d1-554d-5d4d-e69a-a38ded02bb08@arinc9.com>
 <ZBCyqdfaeF/q8oZr@makrotopia.org>
 <c07651cd-27b4-5ba4-8116-398522327d27@arinc9.com>
 <20230314195322.tsciinumrxtw64o5@skbuf>
 <3e3e6a1e-61ba-a6e8-5503-258fb8e949bb@arinc9.com>
 <20230314223413.velxur7gi7snpdei@skbuf>
Content-Language: en-US
From:   =?UTF-8?B?QXLEsW7DpyDDnE5BTA==?= <arinc.unal@arinc9.com>
In-Reply-To: <20230314223413.velxur7gi7snpdei@skbuf>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 15.03.2023 01:34, Vladimir Oltean wrote:
> On Tue, Mar 14, 2023 at 11:59:40PM +0300, Arınç ÜNAL wrote:
>> Look, I don't ask for renaming just for the sake of renaming things. I see a
>> benefit which would make things clearer.
>>
>> If you rather mean to, know the driver very well, by saying do 100 useful
>> commits on the driver beforehand, that makes sense. But I think I'm capable
>> of managing this. I've got the time and energy.
> 
> I'm absolutely sure that you're capable of renaming mt7530 to mt753x,
> that's outside the question. That change can be made without even paying
> too much attention to the code, which is exactly the problem. If the
> proposal is to touch mt7530_read(), mt7530_write(), mt7530_rmw()
> (which it seems to be), then that's pretty much the entire driver.
> 
> Sorry for being skeptical by default, but generally such refactoring is
> done by people who have the commitment to stay around when shit hits the
> fan. Think of it as minimizing the time wasted by others due to that
> refactoring. That could be time spent by reviewers looking at the code
> being changed while trying to identify latent bugs; could be time spent
> by someone who fixes a bug that doesn't backport all the way to stable
> kernels because it conflicts with the refactoring. Ideally, after a
> large refactoring, you would be sufficiently active to find and fix bugs
> before others do, and have an eye for problematic code. Respectfully,
> you still need to prove all these things. It also helps a lot if you
> build a working relationship with the driver maintainers, or if you gain
> their trust and become a maintainer yourself. Otherwise, more work will
> just fall on the shoulders of fallback maintainers who don't have the
> hardware. If there is a self-sustaining development community and they
> take care of everything, I really have zero problems with large
> refactoring done even by newbies. But the mt7530 maintainers have gone
> pretty silent as of late, and I, as a fallback maintainer with no
> hardware, have had to send 2 bug fixes to the mt7530 and 1 to the
> mtk_eth_soc driver in the past month, to address the reports. Give me a
> reason not to refuse more potential work :)

Now, I can find bugs if it's something that would appear on a daily use 
of the hardware, like those bugfixes you mentioned which I reported to 
you. I'm not confident in fixing them myself (yet!) due to my very 
slowly learning C but I'm willing to stick around for years to come so 
who knows what happens in a few years. I already do keep an eye on a 
very small problematic code at least.

I can be around as a maintainer to help backporting bugfixes that 
wouldn't apply cleanly due to my refactoring. So I don't add more 
workload to fallback maintainers like yourself. But that's all I can 
promise to maintain for now, not because of availability but experience, 
or rather the lack thereof.

Arınç