Re: [PATCH] arm64: dts: mt7622: fix switch probe on bananapi-r64

[Arınç ÜNAL]

On 30/07/2024 19:04, Krzysztof Kozlowski wrote:
> On 30/07/2024 13:22, arinc.unal@xxxxxxxxxx wrote:
> > > > > Reminder: try to not see a revert as a bad thing. It's just means
> > > > > "not
> > > > > ready yet, revert and we'll try again later" -- that's actually
> > > > > something Linus wrote just a few hours ago:
> > > > > https://lore.kernel.org/lkml/CAHk-=wgQMOscLeeA3QXOs97xOz_CTxdqJjpC20tJ-7bUdHWtSA@xxxxxxxxxxxxxx/
> > > >
> > > > Except it is ready and trying again is my responsibility, which means
> > > > unnecessary work for me to do. I've already got a ton of things to do.
> > > > Applying the device tree patch resolves this regression; no reverts
> > > > needed.
> > > > And then there's the patch in the works by Daniel that will address
> > > > all the
> > > > remaining cases outside of the reported regression.
> > >
> > > The commit that fixes your breakage in a way that does *not* please me
> > > (because of older devicetrees being still broken with the new driver)
> > > was
> > > picked and it is in v6.11-rc1.
> > >
> > > I had to do this because I value the community (in this case, the
> > > users) much
> > > more than trying to make an arrogant developer to act in a
> > > community-friendly
> > > manner while leaving things completely broken.
> > >
> > > That said, remembering that we're humans and, as such, it's normal to
> > > get something
> > > wrong during the development process, I want to remind you that:
> > >
> > >   1. A series that creates regressions is *not* good and *not* ready to
> > > be
> > >      upstreamed; and
> > >   2. As a maintainer, you have the responsibility of not breaking the
> > > kernel,
> > >      not breaking devices and not breaking currently working
> > > functionality; and
> > >   3. Devicetrees being wrong (but working) since day 0 is not an excuse
> > > to break
> > >      functionality; and
> > >   4. Blaming the one who introduced the devicetree (you're doing that,
> > > since you
> > >      are blaming the devicetree being wrong) isn't solving anything and
> > > will not
> > >      magically make your code acceptable or good; and
> > >   5. If you push a wrong commit, there's nothing to be ashamed of; and
> > >   6. If you make a mistake, you should recognize that and find a way to
> > >      make things right, that should be done for the community, not for
> > >      yourself; and
> > >   7. You shall respect the community: in this case, with your arrogant
> > > behavior
> > >      you did *not* respect the users.
> > >
> > > P.S.: The right way of making such change is to:
> > >        1. Avoid breaking currently working devices by making sure that
> > > their DT
> > >           still works with the new driver; and
> > >        2. If breakage is unavoidable, make it so one kernel version has
> > > a fix that
> > >           works with both old and new driver, and the next version
> > > introduces the
> > >           breakage. N.2 should ideally never happen, anyway.
> > >
> > > Let's wrap up this matter now - I don't want to spend any more word,
> > > nor time,
> > > on this, as I really have nothing else to say.
> > >
> > > Best regards,
> > > Angelo
> >
> > To be clear, I only became aware that my patch was picked by reading
> > this
> > email. It is clear that we have different views. To that extend, all of
> > what you have written above can be answered to by reading what I have
> > already written in this thread. Therefore, I don't see any wrongdoing
> > from
> > my side and invite everyone to fully read this thread to draw their own
> > conclusions; something you seem not to have done. And I'm not the one,
> > calling people names here. I can only offer my respect for hard working
> > people.
> >
> > In my view, your behaviour of not applying a devicetree patch before a
> > Linux driver patch was applied, and then not replying to any arguments
> > whatsoever, was keeping the devicetree files hostage until your demands
>
> Hm, why ever DTS patch should be applied before driver patch is? This
> clearly suggests ABI break. You proposed to fix ABI issue by fixing DTS,
> which is not the way, because it literally fixes nothing. You got
> comments - fix the driver to be backwards compatible.

As I argued in this thread, I see no ABI issue here. I proposed to fix
broken devicetrees, nothing more. Please read the full thread to understand
where I'm coming from.

Arınç