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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9f5a3dc5-d0f8-4172-a4b4-867919612a2d@collabora.com>
Date: Wed, 29 Oct 2025 12:05:33 +0100
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Chen-Yu Tsai <wenst@...omium.org>, mathieu.poirier@...aro.org
Cc: linux-remoteproc@...r.kernel.org, arnd@...db.de, andersson@...nel.org,
 matthias.bgg@...il.com, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 kernel@...labora.com
Subject: Re: [PATCH v2] remoteproc: mtk_scp: Construct FW path if
 firmware-name not present

Il 29/10/25 10:14, Chen-Yu Tsai ha scritto:
> On Wed, Oct 15, 2025 at 4:41 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@...labora.com> wrote:
>>
>> After a reply on the mailing lists [1] it emerged that the DT
>> property "firmware-name" should not be relied on because of
>> possible issues with firmware versions.
>> For MediaTek SCP, there has never been any firmware version vs
>> driver version desync issue but, regardless, the firmwares are
>> always using the same name and they're always located in a path
>> with a specific pattern.
>>
>> Instead of unconditionally always relying on the firmware-name
>> devicetree property to get a path to the SCP FW file, drivers
>> should construct a name based on what firmware it knows and
>> what hardware it is running on.
>>
>> In order to do that, add a `scp_get_default_fw_path()` function
>> that constructs the path and filename based on two of the infos
>> that the driver can get:
>>   1. The compatible string with the highest priority (so, the
>>      first one at index 0); and
>>   2. The type of SCP HW - single-core or multi-core.
>>
>> This means that the default firmware path is generated as:
>>   - Single core SCP: mediatek/(soc_model)/scp.img
>>     for example:     mediatek/mt8183/scp.img;
>>
>>   - Multi core SCP:  mediatek/(soc_model)/scp_c(core_number).img
>>     for example:     mediatek/mt8188/scp_c0.img for Core 0, and
>>                      mediatek/mt8188/scp_c1.img for Core 1.
> 
> I know this patch has been applied, but this scheme doesn't actually
> follow what is already in the linux-firmware repository.
> 
> For all the supported platforms, the first core, even for multi core SCP,
> already have their firmware uploaded as just "scp.img". Multicore SCP
> is seen in MT8195 and MT8188.

The only one that is affected is MT8188, which needs a rename or a symlink in
linux-firmware.

MT8195 is not affected by this change, because the SCP is used as single-core,
hence this code will look for scp.img and not for scp_c0.img.

> 
> 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.

Please remember that some of those SoCs (including MT8195) allow the SCP to be
configured as *either* single-core *or* dual-core - and usually firmwares for
single-core configurations are not compatible with dual-core ones, because of
the SRAM carveout/usage.

Cheers,
Angelo

> 
> 
> ChenYu