linux-kernel - Re: [RFC] bus: mhi: core: Load firmware asynchronous

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: <87k0g4n97l.fsf@tynnyri.adurom.net>
Date:   Thu, 16 Dec 2021 12:19:10 +0200
From:   Kalle Valo <kvalo@...nel.org>
To:     Thomas Weißschuh <linux@...ssschuh.net>
Cc:     Hemant Kumar <hemantk@...eaurora.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        linux-kernel@...r.kernel.org, mhi@...ts.linux.dev,
        linux-arm-msm@...r.kernel.org,
        Mario Limonciello <Mario.Limonciello@....com>,
        Richard Hughes <hughsient@...il.com>,
        ath11k@...ts.infradead.org
Subject: Re: [RFC] bus: mhi: core: Load firmware asynchronous

Thomas Weißschuh <linux@...ssschuh.net> writes:

> This gives userspace the possibility to provide the firehose bootloader
> via the sysfs-firmware-API instead of having to modify the global
> firmware loadpath.
>
> Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
>
> ---
>
> Please note that this is not tested yet, as I don't have access to a matching
> firmware file.
> This submission is to gather general feedback from the maintainers and then
> Richard will do the actual testing, while I'll do the development.
>
> This patch is should not have any impact beyond moving from request_firmware()
> to request_firmware_nowait() and the involved code reshuffle.

Related to firmware loading, for ath11k I have a different kind of need
for firmware handling in MHI. Instead of providing the firmware name to
MHI and MHI subystem loading the firmware from user space, I would like
to ath11k load the firmware from user space and just provide a pointer
to the firmware data.

The long story here is that currently ath11k pci devices have two
different firmware files, amss.bin and m3.bin. amss.bin is loaded via
MHI and m3.bin via QMI. What I would like do is to create one container
file firmware-2.bin and it would contain amss.bin, m3.bin and various
meta data needed by ath11k. ath11k would then parse firmware-2.bin and
provide pointer to amss.bin data for MHI.

We already use similar firmware-2.bin file in ath10k, but of course
ath10k doesn't need MHI so this hasn't been an issue before. We need
firmware-2.bin files because of two reasons: seamless backwards
compatibility and a reliable way to provide meta data to the driver.

Thoughts about this?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches