Re: [PATCH v2] remoteproc: mtk_scp: Construct FW path if firmware-name not present

["Macpaul Lin (林智斌)" <Macpaul.Lin@mediatek.com>]

On Thu, 2025-10-30 at 10:29 +0100, AngeloGioacchino Del Regno wrote:
> Il 30/10/25 10:10, Arnd Bergmann ha scritto:
> > On Thu, Oct 30, 2025, at 09:21, Chen-Yu Tsai wrote:
> > > On Wed, Oct 29, 2025 at 7:05 PM AngeloGioacchino Del Regno
> > > <angelogioacchino.delregno@collabora.com> wrote:
> > > > 
> > > > > 
> > > > > I guess I can send a followup patch?
> > > > 
> > > > The only followup patch that I deem to be necessary is one
> > > > adding a symlink
> > > > or renaming for MT8188's SCP and nothing else.
> > > 

Dear Moudy, just a remind please help to double check if a rename or
link for MT8188's SCP image is required.

> > > The firmware was uploaded in March of 2025, and is packaged in
> > > Debian
> > > Trixie, and was also backported to Bookworm. Either adding a
> > > symlink or
> > > renaming it won't trickle down to users for some time. So this
> > > seems
> > > like a possible ABI break, where the ABI is the file name.
> > > 

> Just as a clarification:
> 
> Exactly, SCP hasn't been enabled in the kernel in any release in the
> specific
> case of MT8188, so this is not breaking anything, and it's not
> creating any
> regression.
> 

Some boards supports SystemReady IR might require firmware loading
if they're using Debian, openSuse, Ubuntu offical ARM image, etc.
We'll need to check when these distros could update to the latest
linux-firmware with which verison of official release. For example 
, the CD image of Trixie, LE 16, Ubuntu 25.10 (and the coming 26.04),
etc.

Maybe the worse case is to support a backward compatible firmware
loading if there is a 'firmware-name' existed in some devices already
sold. I guess there is only few devices supports CD image installation
in real world deployment will be affected since the multimedia support 
just ready a few months ago in the upstream kernel.

> > 
> > It's normally up to the kernel driver to know about the firmware
> > file names and the order of trying the possible fallbacks, which
> > is exactly why I originally asked to not rely on the property
> > from dtb.
> > 
> > If you want a symlink in linux-firmware, that would go the other
> > way, pointing the old filename to the new location.
> > 
> >      Arnd
> 
> Cheers!
> Angelo

Do we need a following patch to remove the firmware-names in dts nodes?
I've made one patch but not sure if we should keep these properties 
in current dts for old devices.

Best regards,
Macpaul Lin