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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Dec 2021 14:55:16 -0800
From:   Hemant Kumar <hemantk@...eaurora.org>
To:     Thomas Weißschuh <linux@...ssschuh.net>
Cc:     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>
Subject: Re: [RFC] bus: mhi: core: Load firmware asynchronous



On 12/13/2021 10:32 PM, Thomas Weißschuh wrote:
> On 2021-12-13 16:07-0800, Hemant Kumar wrote:
>> On 12/10/2021 8:16 AM, Thomas Weißschuh wrote:
>>> 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.
>> what are we achieving by moving to async ver of the firmware load ? MHI boot
>> flow can not do anything until BHI load is over. Is the intention eventually
>> to enable firmware fallback mechanism  and manually load the firmware ?
> 
> The goal is to provide the firehose bootloader (qcom/prog_firehose_sdx24.mbn)
> via the firmware fallback mechanism when upgrading the firmware on the device
> via the firehose protocol.
> 
> This bootloader firmware is not part of linux-firmware but provided as part of
> each firmware update package, so it is not installed statically on the system.
> 
> I will extend the commit message with this information.

For my understanding i have follow up question. As per the kernel doc
https://www.kernel.org/doc/html/latest/driver-api/firmware/fallback-mechanisms.html

If CONFIG_FW_LOADER_USER_HELPER enabled but 
CONFIG_FW_LOADER_USER_HELPER_FALLBACK is disabled, only the custom 
fallback mechanism is available and for the request_firmware_nowait() call.

Custom fall back mechanism says
Users of the request_firmware_nowait() call have yet another option 
available at their disposal: rely on the sysfs fallback mechanism but 
request that no kobject uevents be issued to userspace. Original logic 
behind this was that utilities other than udev might be required to 
lookup firmware in non-traditional paths

Your patch is passing uevent flag as true which means you are relying on 
uevent to be issued to userspace. How do you plan to update the firmware 
path ? Alternatively firmware class provides a module param to specify 
the firmware path /sys/module/firmware_class/parameters/path.
> 
> PS: The current patch is missing 'return' after calls to
> 'mhi_fw_load_finish()', this will be corrected in v2.
> 

Thanks,
Hemant
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, a Linux Foundation Collaborative Project