[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 at arinc9.com 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@mail.gmail.com/
>>>>
>>>> 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ç