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ç
