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] [thread-next>] [day] [month] [year] [list]
Message-Id: <f434165f-1717-41ff-93e4-9be5b7fca929@app.fastmail.com>
Date: Thu, 30 Oct 2025 10:10:37 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Chen-Yu Tsai" <wenst@...omium.org>,
 "AngeloGioacchino Del Regno" <angelogioacchino.delregno@...labora.com>
Cc: "Mathieu Poirier" <mathieu.poirier@...aro.org>,
 linux-remoteproc@...r.kernel.org, "Bjorn Andersson" <andersson@...nel.org>,
 "Matthias Brugger" <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

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@...labora.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.
>
> 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?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ