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ç
