Message-ID: <bb7e9cae-d627-4f38-9da2-b40fb3c349fe@arinc9.com>
Date: Tue, 25 Jun 2024 11:17:09 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: Linux regressions mailing list <regressions@...ts.linux.dev>,
 Paolo Abeni <pabeni@...hat.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 Daniel Golle <daniel@...rotopia.org>, frank-w@...lic-files.de,
 Frank Wunderlich <linux@...web.de>, Rob Herring <robh@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>
Subject: Re: [PATCH] arm64: dts: mt7622: fix switch probe on bananapi-r64

On 25/06/2024 09.57, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 25.06.24 08:17, Arınç ÜNAL wrote:
>> On 25/06/2024 08.56, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> On 17.06.24 13:08, Arınç ÜNAL wrote:
>>>> On 17/06/2024 11:33, Linux regression tracking (Thorsten Leemhuis)
>>>> wrote:
>>>> [...]
>>>> I've submitted a patch series that fixes the regression. Angelo argued
>>>> against the way the regression is fixed. I've very clearly argued
>>>> back why
>>>> I find Angelo's approach wrong. There's been no response back. I don't
>>>> understand why reverting the patch is the likely outcome
>>>
>>> Long story short: because that how things like that are handled in the
>>> Linux kernel project, as Linus wants it like that. See some of the
>>> quotes from https://docs.kernel.org/process/handling-regressions.html
>>> for details.
>>>
>>>> whilst the
>>>> standing argument points towards applying the said patch series. If a
>>>> revert happens before this discussion with Angelo finalises, this
>>>> will set
>>>> a precedent that will tell maintainers that they can have their way
>>>> by just
>>>> not replying to the ongoing discussions.
>>>>
>>>> That said, the decision of resolving the regression by either
>>>> reverting the
>>>> patch or applying the patch series shall not depend on whether or not
>>>> Angelo is pleased but rather there're no counter-arguments left on the
>>>> points brought, meaning the decision shall be made depending on the
>>>> argument that stands.
>>>>
>>>> Therefore, I suggest that unless Angelo responds back with a
>>>> counter-argument in the window of a week or two, as you've described, my
>>>> patch series shall be applied.
>>>
>>> It looks more and more like we are stuck here (or was there progress and
>>> I just missed it?) while the 6.10 final is slowly getting closer. Hence:
>>
>> There hasn't been progress at all. I believe I have clearly described the
>> way out of this issue.
>>
>>> AngeloGioacchino, should we ask the net maintainers to revert
>>> 868ff5f4944aa9 ("net: dsa: mt7530-mdio: read PHY address of switch from
>>> device tree") for now to resolve this regression? Reminder, there is
>>> nothing wrong with that commit per se afaik, it just exposes a problem
>>> that needs to be fixed first before it can be reapplied.
>>
>> Are you suggesting the patch shall be reverted first, then the DT patch
>> applied, then the reverted patch applied back?
> 
> Yeah.
> 
>> If only one of the first two
>> steps were done, it would fix the regression so I don't understand why go
>> through this tedious process when we can quite simply apply the DT patch to
>> resolve the regression.
> 
> Which DT patch do you mean here? Your series or the one from Frank at
> the start of the thread (the one you seems to be unhappy about iirc, but
> I might be wrong there)?

My series, as arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts needs to be
addressed too to resolve the regression.

> 
> Anyway, to answer the statement: because the maintainers that would have
> to accept the DT patch to resolve the problem apparently are not happy
> with it -- and nobody seems to be working on providing patches that make
> them happy which are also acceptable at this point of the devel cycle;
> so as it looks like currently to prevent the regression from entering
> 6.10 reverting the net change is the only option left.

I've already made my case regarding the situation with the DT patch. I
can't provide new patches because Angelo did not acknowledge my points yet.
I maintain the net driver and I too won't be happy with a revert on the
driver.

> 
>> Keep in mind that I maintain the MT7530 DSA subdriver and the company I
>> work with has got boards that uses the functionality the commit
>> 868ff5f4944aa9 ("net: dsa: mt7530-mdio: read PHY address of switch from
>> device tree") brings.
> 
> Don't see a revert as setback at all, that's just normal for the kernel.
> I'm not the one that will decide about this anyway. And everyone
> involved afaics would like to prevent a revert. But it seems more and
> more likely that we are not getting there in time for the 6.10 release
> (or ideally -rc6 or -rc7 to allow some testing, as last-minute reverts
> can cause new problems).

I am still calling for the simple procedure of applying the DT patch to
resolve the regression.

Arınç

Powered by blists - more mailing lists