Message-ID: <d4009f46-618c-46c3-8f35-a8db9150862e@arinc9.com>
Date: Wed, 26 Jun 2024 06:07:04 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Linux regressions mailing list <regressions@...ts.linux.dev>,
 Paolo Abeni <pabeni@...hat.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 11.49, AngeloGioacchino Del Regno wrote:
> Il 25/06/24 10:17, Arınç ÜNAL ha scritto:
>> 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.
>>>
> 
> Sorry, I've lost your reply in the long stack of emails that I get every day.
> 
> I'm not suggesting to revert the patch, but to fix it such that it does not
> break devices using old devicetrees, as it was the case before.
> 
> Even though, in a way, when you update the kernel, you do also update the
> devicetrees with it just because it's almost effortless to do so, doing that
> is not mandatory.
> 
> ...and that's why the driver, which was - in a way - faulty before, getting
> the switch to work even though the devicetree node was wrong, must still be
> compatible.
> 
> I do want to apply the devicetree fix, but I also do *not* want to see *driver*
> changes that go against the backward compatibility rule of devicetree when this
> is not strictly necessary (when it is - it's okay to make an exception)...
> 
> ...and this is not one of the cases in which it's strictly necessary.

I understand that you receive emails often. It seems you've not read my
point of view in the previous emails because of it, so it is preventing us
from having a proper discussion to come to a mutual agreement. I don't
intend to repeat myself for it to be lost in your inbox again.

I'm hoping that you manage to read this; Daniel has been working on a patch
[1] to make old device trees not hosted on the Linux repository with PHY
address wrongfully described as "0" work.

As I see the extend of the reported regression is limited to the BPI-R64
board, fixing the device tree source file for it - and mt7622-rfb1.dts as
the only remaining DTS file with wrong PHY address described in the Linux
repository - is enough to resolve the regression. Then Daniel's patch can
come in to address the device tree source files I've described above.
Although I don't find that patch necessary, I won't stand against it.

So I suggest to apply my DT patch series [2] without taking any other steps
to resolve the reported regression.

[1] https://lore.kernel.org/all/11f5f127d0350e72569c36f9060b6e642dfaddbb.1714514208.git.daniel@makrotopia.org/
[2] https://lore.kernel.org/all/20240314-for-mediatek-mt7531-phy-address-v1-0-52f58db01acd@arinc9.com/

Arınç

Powered by blists - more mailing lists