Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

On Sat, Feb 06, 2021 at 03:35:54PM +0100, Arnd Bergmann wrote:

On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski [off-list ref] wrote:

quoted

On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:

quoted

----------------------------------------------------------------
Samsung DTS ARM changes for v5.12

1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
   it suspend/resume cycle.
2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
3. Correct the voltages of Samsung GT-I9100 charger and add top-off
   charger.

Hi everyone,

Any progress or new comments about this pull request?

Hi Krzysztof,

Sorry for not getting back to you on this earlier. I discussed this with
Olof the other day and we decided to merge this, I just haven't
gone through the pull requests over the past few days. My plan is
to do the next round on Monday.

That said, I'm still not happy about the patch we discussed in the
other email thread[1] and I'd like to handle it a little more strictly in
the future, but I agree this wasn't obvious and we have been rather
inconsistent about it in the past, with some platform maintainers
handling it way more strictly than others.

Thank you for explanation. I would love to receive kind of guidance,
best practices, guide for future patches. I will them write it down and
try to follow during my review. However it made me a sad that a patch,
adhering in my mind to all rules, was postponing the pull request.

I've added the devicetree maintainers and a few other platform
maintainers to Cc here, maybe they can provide some further
opinions on the topic so we can come to an approach that
works for everyone.

My summary of the thread in [1] is there was a driver bug that
required a DT binding change. Krzysztof and the other involved
parties made sure the driver handles it in a backward-compatible
way (an old dtb file will still run into the bug but keep working
with new kernels), but decided that they did not need to worry
about the opposite case (running an old kernel with an updated
dtb). I noticed the compatibility break and said that I would
prefer this to be done in a way that is compatible both ways,
or at the minimum be alerted about the binding break in the
pull request, with an explanation about why this had to be done,
even when we don't think anyone is going to be affected.

What do others think about this? Should we generally assume
that breaking old kernels with new dtbs is acceptable, or should
we try to avoid it if possible, the same way we try to avoid
breaking new kernels with old dtbs? Should this be a platform
specific policy or should we try to handle all platforms the same
way?

Good summary, thanks Arnd. I would like to add that the discussed change
was bringing a new compatible. It was saying: hey, this hardware so far we
treated as old one, but it's not, sorry, it is different, so here you
have a new compatible with a change in few properties as well (and new
bindings which appeared a release earlier).

Best regards,
Krzysztof

          Arnd

[1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/ (local)