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@xxxxxxxxxxxxxx/
[2] https://lore.kernel.org/all/20240314-for-mediatek-mt7531-phy-address-v1-0-52f58db01acd@xxxxxxxxxx/
Arınç
