| Message ID | b4383f23-0adc-b9de-a1d9-abd1c2f82b27@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [GIT,PULL] arm: mediatek: DT updates for v5.19 | expand |
On Fri, May 13, 2022 at 1:21 PM Matthias Brugger <matthias.bgg@gmail.com> wrote: > > Hi Arnd and Olof, > > 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? 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? Arnd
On 13/05/2022 14:11, Arnd Bergmann wrote: > On Fri, May 13, 2022 at 1:21 PM Matthias Brugger <matthias.bgg@gmail.com> wrote: >> >> Hi Arnd and Olof, >> >> 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. > 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. 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. Regards, Matthias [1] https://lore.kernel.org/linux-mediatek/20220117070510.17642-2-yong.wu@mediatek.com/
On Fri, May 13, 2022 at 6:06 PM Matthias Brugger <matthias.bgg@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@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/
Hi Arnd and Olof, 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. Regards, Matthias --- The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17: Linux 5.18-rc1 (2022-04-03 14:08:21 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/ tags/v5.18-next-dts32 for you to fetch changes up to a044e6a0883bcd4ad71849c97f79fd213e940077: arm: dts: mediatek: Get rid of mediatek, larb for MM nodes (2022-04-22 15:49:12 +0200) ---------------------------------------------------------------- Delete no longer needed properties of MediaTek Larbs for MT2701. ---------------------------------------------------------------- Yong Wu (1): arm: dts: mediatek: Get rid of mediatek, larb for MM nodes arch/arm/boot/dts/mt2701.dtsi | 2 -- arch/arm/boot/dts/mt7623n.dtsi | 5 ----- 2 files changed, 7 deletions(-)