[PATCH] arm64: dts: mediatek: mt8188-geralt: drop firmware-name from first SCP core

[PATCH] arm64: dts: mediatek: mt8188-geralt: drop firmware-name from first SCP core

[Chen-Yu Tsai]

Arnd pointed out that having firmware-name in the device tree is wrong.
Drop it.

Fixes: e36be19823f0 ("arm64: dts: mediatek: mt8188-geralt: Enable first SCP core")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
index 7fedbacdac44..8e423504ec05 100644
--- a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
@@ -1166,7 +1166,6 @@ &scp_cluster {
 &scp_c0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&scp_pins>;
-	firmware-name = "mediatek/mt8188/scp.img";
 	memory-region = <&scp_mem_reserved>;
 	status = "okay";
 };
-- 
2.52.0.rc1.455.g30608eb744-goog

Re: [PATCH] arm64: dts: mediatek: mt8188-geralt: drop firmware-name from first SCP core

[AngeloGioacchino Del Regno]

Il 19/11/25 08:02, Chen-Yu Tsai ha scritto:
> Arnd pointed out that having firmware-name in the device tree is wrong.
> Drop it.
> 
> Fixes: e36be19823f0 ("arm64: dts: mediatek: mt8188-geralt: Enable first SCP core")

Fixes here is .. well, right, but wrong - as if you "fix" that in previous kernel
releases, you will create regressions :-)

For all of the currently supported boards, I was planning to temporarily leave the
firmware-name properties in place for one kernel version (v6.19) and remove it from
all of them at once, for kernel v6.20.

I'd be okay if you send a commit or a series removing firmware-name from all of
them, without any Fixes tag and without any "fix" word (so that we avoid autosel
backports at all costs!), but keep in mind that I'd pick that in the next merge
window, and not right now.

Thanks!
Angelo

> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
>   arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
> index 7fedbacdac44..8e423504ec05 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
> @@ -1166,7 +1166,6 @@ &scp_cluster {
>   &scp_c0 {
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&scp_pins>;
> -	firmware-name = "mediatek/mt8188/scp.img";
>   	memory-region = <&scp_mem_reserved>;
>   	status = "okay";
>   };

Re: [PATCH] arm64: dts: mediatek: mt8188-geralt: drop firmware-name from first SCP core

[Chen-Yu Tsai]

On Wed, Nov 19, 2025 at 4:31 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 19/11/25 08:02, Chen-Yu Tsai ha scritto:
> > Arnd pointed out that having firmware-name in the device tree is wrong.
> > Drop it.
> >
> > Fixes: e36be19823f0 ("arm64: dts: mediatek: mt8188-geralt: Enable first SCP core")
>
> Fixes here is .. well, right, but wrong - as if you "fix" that in previous kernel
> releases, you will create regressions :-)

This is a fix because the commit in question was merged in v6.18-rc1
and v6.18 hasn't been released yet. So you should pick it now for
v6.18.

> For all of the currently supported boards, I was planning to temporarily leave the
> firmware-name properties in place for one kernel version (v6.19) and remove it from
> all of them at once, for kernel v6.20.

OK. So I guess the plan is to have MT8188 SCP working in v6.18 based
on the current name then?

> I'd be okay if you send a commit or a series removing firmware-name from all of
> them, without any Fixes tag and without any "fix" word (so that we avoid autosel
> backports at all costs!), but keep in mind that I'd pick that in the next merge
> window, and not right now.

We can avoid autosel with:

     Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present

(See stable-kernel-rules for the whole paragraph.)

After the blobs in the firmware repo have been renamed, we then explicitly
backport the change to stable. I think that works out better? And the only
one that needs to be timed is the MT8188 change anyway.

How does that sound?


ChenYu

> Thanks!
> Angelo
>
> > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> > ---
> >   arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi | 1 -
> >   1 file changed, 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
> > index 7fedbacdac44..8e423504ec05 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
> > @@ -1166,7 +1166,6 @@ &scp_cluster {
> >   &scp_c0 {
> >       pinctrl-names = "default";
> >       pinctrl-0 = <&scp_pins>;
> > -     firmware-name = "mediatek/mt8188/scp.img";
> >       memory-region = <&scp_mem_reserved>;
> >       status = "okay";
> >   };
>
>

Re: [PATCH] arm64: dts: mediatek: mt8188-geralt: drop firmware-name from first SCP core

[AngeloGioacchino Del Regno]

Il 19/11/25 09:41, Chen-Yu Tsai ha scritto:
> On Wed, Nov 19, 2025 at 4:31 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> Il 19/11/25 08:02, Chen-Yu Tsai ha scritto:
>>> Arnd pointed out that having firmware-name in the device tree is wrong.
>>> Drop it.
>>>
>>> Fixes: e36be19823f0 ("arm64: dts: mediatek: mt8188-geralt: Enable first SCP core")
>>
>> Fixes here is .. well, right, but wrong - as if you "fix" that in previous kernel
>> releases, you will create regressions :-)
> 
> This is a fix because the commit in question was merged in v6.18-rc1
> and v6.18 hasn't been released yet. So you should pick it now for
> v6.18.
> 
>> For all of the currently supported boards, I was planning to temporarily leave the
>> firmware-name properties in place for one kernel version (v6.19) and remove it from
>> all of them at once, for kernel v6.20.
> 
> OK. So I guess the plan is to have MT8188 SCP working in v6.18 based
> on the current name then?
> 

Any firmware in linux-firmware that needs a rename will still need to retain
compatibility with old kernel versions: it doesn't matter if scp.img will be
renamed because we will anyway need a symlink.

This does effectively mean that, for MT8188, the current "scp.img" will be
"reachable" as both "scp.img" and as "scp_c0.img" - so timing for removal of
the firmware-name property in here doesn't matter at all.

There's no rush.

>> I'd be okay if you send a commit or a series removing firmware-name from all of
>> them, without any Fixes tag and without any "fix" word (so that we avoid autosel
>> backports at all costs!), but keep in mind that I'd pick that in the next merge
>> window, and not right now.
> 
> We can avoid autosel with:
> 
>       Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present
> 
> (See stable-kernel-rules for the whole paragraph.)
> 
> After the blobs in the firmware repo have been renamed, we then explicitly
> backport the change to stable. I think that works out better? And the only
> one that needs to be timed is the MT8188 change anyway.
> 
> How does that sound?
> 

We can avoid autosel with that, sure - but I still don't really judge it as being
a fix, as not specifying firmware-name is something new, even if it was technically
wrong from the beginning.
(Someone may or may not agree with me, but that's another story.)

In the past, it wasn't a problem - it's a problem now, and a resolved one - but
this doesn't mean that having this property was a "broken" behavior in the past.

It worked. And it was fine.

Even if I don't see the actual benefit, I don't mind having this backported to
v6.18 when it'll be time to pick this commit along with the others, but again
I don't understand why you're feeling like this is urgent.

For how I see it: -> it's not urgent! <-

There has to be no regression on the supported boards - with or without - this
property being present.

The only one that can be just renamed without *caring* about symlinks is MT8189,
as it "never worked" upstream (as in, there, a rename without a symlink will not
create any regression) simply because MT8189 never got any firmware-name property
(actually, never got any devicetree at all, even).

Again, timing is not important; the sooner the better, yes, but at the same level
of importance as any other *functionality improvement* (not fixes), nothing more
and nothing less.

Does that clarify the course of action for you?

Cheers,
Angelo

> 
> ChenYu
> 
>> Thanks!
>> Angelo
>>
>>> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
>>> ---
>>>    arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi | 1 -
>>>    1 file changed, 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
>>> index 7fedbacdac44..8e423504ec05 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
>>> @@ -1166,7 +1166,6 @@ &scp_cluster {
>>>    &scp_c0 {
>>>        pinctrl-names = "default";
>>>        pinctrl-0 = <&scp_pins>;
>>> -     firmware-name = "mediatek/mt8188/scp.img";
>>>        memory-region = <&scp_mem_reserved>;
>>>        status = "okay";
>>>    };
>>
>>