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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <febb8bb9-ab4f-4bf1-a0af-84c5382c3419@collabora.com>
Date: Thu, 30 Oct 2025 10:33:20 +0100
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Chen-Yu Tsai <wenst@...omium.org>
Cc: mathieu.poirier@...aro.org, 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 30/10/25 09:21, Chen-Yu Tsai ha scritto:
> On Wed, Oct 29, 2025 at 7:05 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@...labora.com> wrote:
>>
>> 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.
> 
> 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.
> 
> Or maybe you don't consider it as such because SCP hasn't been enabled
> in the kernel in any release yet?
> 
>> 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.
> 
> For MT8188, whether the current blob is dual core compatible needs to be
> checked. The blob upstreamed to linux-firmware was built locally by
> MediaTek engineers and is not what we ship with ChromeOS devices.

The current blob is dual core compatible.

We assisted MediaTek (Moudy) in choosing and validating the SCP firmware for
MT8188, and made sure that it uses only one core, and that doesn't clash with
the second core SRAM.

Cheers,
Angelo

> 
> 
> ChenYu