[GIT PULL] arm: mediatek: DT updates for v5.19

[Arnd Bergmann]

On Fri, May 13, 2022 at 6:06 PM Matthias Brugger <matthias.bgg at gmail.com> wrote:
> On 13/05/2022 14:11, Arnd Bergmann wrote:
> > On Fri, May 13, 2022 at 1:21 PM Matthias Brugger <matthias.bgg at gmail.com> wrote:
> >> Please have a look on the below 32 bit DT updates for v5.19. Apologies for the
> >> late pull request but I got sick and needed my time to recover.
> >
> >> Yong Wu (1):
> >>         arm: dts: mediatek: Get rid of mediatek, larb for MM nodes
> >
> > Can you clarify what this means for backwards compatibility? I see old kernels
> > used to parse these properties, does that mean that the updated DT is no
> > longer compatible with them?
> >
>
> My understanding is, that backwards compatibility is given when using older DT
> with newer kernel. This should be the common case, normally you update your
> software but nearly never your FW. No compatibility is given when using older
> kernel with newer DT.
>
> I think that's an ongoing debate if we should provide backwards compatibility
> for both kernel and DT.

I agree that the case of old dt with new kernel is more important, but I still
want to hear about it when the other case (new dt on old kernel) breaks,
and why it's done.  There are clearly use cases for both forms of compatibility,
and there are reasons for ignoring them, the key is to communicate it clearly.

> > If you break compatibility, this should only be done for exceptional reasons,
> > and explain the tradeoffs. What is the oldest kernel that is still compatible
> > with the updated DT files, and why can't we just keep the properties around?
> >
>
> First kernel version that does not work with the old DT will be v5.18. This
> patch is the outcome of a change in the yaml file [1] which has a Acked-by from
> Rob. I double checked and I wasn't able to find the mail where Rob did give his
> Acked-by... Yong, can you provide a link to that email? I can see you added the
> Acked-by in v2 of the series.
>
> One thing that comes to mind, that we mark the larb phandle as deprecated in the
> yaml file, instead of deleting it. Then we could keep that in the DT files,
> although newer kernels won't work with that. Another option is, to add the code
> deleted by
> ba3cd6714aed ("media: mtk-jpeg: Get rid of mtk_smi_larb_get/put")
>
> back as fallback for older DTs. Although I fear there is much more things to fix
> in a lot of drivers. DRM, mdp and memory/mtk-smi.c are some that I found in a
> 'quick' look at the problem.
>
> Taking into account that and the fact that we are talking mainly about
> chromebooks and the Bananapi R2 as public available HW, I think we can live with
> the compatibility breakage of newer DTs not working with older kernels.

I'm less worried about the dts files that ship with the kernel than I am about
others that have custom dtbs built into the boot loader but are able to
run mainline kernels. Upgrading kernel and bootloader together is painful
here when you have limited compatibility with older versions, in particular
when you cannot dual-boot multiple kernel versions with the same dtb.

> Anyway as you can see, this patch is just the tip of the ice-berg. So if you
> feel that's something unacceptable we will need to chase people to fix backward
> compatibility.

After some more clarification on IRC, I found that this series has been
in progress since 2019 [2], and as you said, the changes to break compatibility
with pre-5.18 DTB files are getting merged through other trees, so I suppose
also breaking compatibility with old kernels isn't making it much worse.

I'll try to capture this in the merge log.

> [1]
> https://lore.kernel.org/linux-mediatek/20220117070510.17642-2-yong.wu@mediatek.com/

[2] https://lore.kernel.org/lkml/1546318276-18993-2-git-send-email-yong.wu@mediatek.com/