On Wed, Oct 29, 2025 at 7:05 PM AngeloGioacchino Del Regno <[email protected]> wrote: > > Il 29/10/25 10:14, Chen-Yu Tsai ha scritto: > > On Wed, Oct 15, 2025 at 4:41 PM AngeloGioacchino Del Regno > > <[email protected]> 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. ChenYu
