* Re: [GIT PULL] arm: mediatek: DT updates for v5.19
@ 2022-05-13 16:06 ` Matthias Brugger
0 siblings, 0 replies; 12+ messages in thread
From: Matthias Brugger @ 2022-05-13 16:06 UTC (permalink / raw)
To: Arnd Bergmann, Yong Wu, Rob Herring
Cc: arm-soc, SoC Team, moderated list:ARM/Mediatek SoC support,
linux-arm-kernel, Evan Green, AngeloGioacchino Del Regno,
Hans Verkuil
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/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [GIT PULL] arm: mediatek: DT updates for v5.19
@ 2022-05-13 16:06 ` Matthias Brugger
0 siblings, 0 replies; 12+ messages in thread
From: Matthias Brugger @ 2022-05-13 16:06 UTC (permalink / raw)
To: Arnd Bergmann, Yong Wu, Rob Herring
Cc: arm-soc, SoC Team, moderated list:ARM/Mediatek SoC support,
linux-arm-kernel, Evan Green, AngeloGioacchino Del Regno,
Hans Verkuil
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/
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [GIT PULL] arm: mediatek: DT updates for v5.19
2022-05-13 16:06 ` Matthias Brugger
(?)
@ 2022-05-13 21:08 ` Arnd Bergmann
-1 siblings, 0 replies; 12+ messages in thread
From: Arnd Bergmann @ 2022-05-13 21:08 UTC (permalink / raw)
To: Matthias Brugger
Cc: Arnd Bergmann, Yong Wu, Rob Herring, arm-soc, SoC Team,
moderated list:ARM/Mediatek SoC support, linux-arm-kernel,
Evan Green, AngeloGioacchino Del Regno, Hans Verkuil,
Rob Herring, DTML
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/
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [GIT PULL] arm: mediatek: DT updates for v5.19
@ 2022-05-13 21:08 ` Arnd Bergmann
0 siblings, 0 replies; 12+ messages in thread
From: Arnd Bergmann @ 2022-05-13 21:08 UTC (permalink / raw)
To: Matthias Brugger
Cc: Arnd Bergmann, Yong Wu, Rob Herring, arm-soc, SoC Team,
moderated list:ARM/Mediatek SoC support, linux-arm-kernel,
Evan Green, AngeloGioacchino Del Regno, Hans Verkuil,
Rob Herring, DTML
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/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [GIT PULL] arm: mediatek: DT updates for v5.19
@ 2022-05-13 21:08 ` Arnd Bergmann
0 siblings, 0 replies; 12+ messages in thread
From: Arnd Bergmann @ 2022-05-13 21:08 UTC (permalink / raw)
To: Matthias Brugger
Cc: Arnd Bergmann, Yong Wu, Rob Herring, arm-soc, SoC Team,
moderated list:ARM/Mediatek SoC support, linux-arm-kernel,
Evan Green, AngeloGioacchino Del Regno, Hans Verkuil,
Rob Herring, DTML
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/
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 12+ messages in thread