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

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

[Matthias Brugger]

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(-)

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

[Matthias Brugger]

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(-)

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

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

[Matthias Brugger]

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(-)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

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

[Arnd Bergmann]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Matthias Brugger]

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/

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

[Matthias Brugger]

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

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

[Matthias Brugger]

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

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

[Arnd Bergmann]

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/

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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