On Sat, Feb 06, 2021 at 03:35:54PM +0100, Arnd Bergmann wrote: > On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > > On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote: > > > > > > ---------------------------------------------------------------- > > > 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/
