[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <16a44663-808c-2eb4-ea6e-66f51a66f7cf@gmx.com>
Date: Sun, 30 Jul 2023 13:30:34 +0000
From: "Artem S. Tashkinov" <aros@....com>
To: linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Very bad bad firmware loading reporting situation
Hi everyone,
I really dislike how firmware loading is handled by kernel [modules]:
* Many modules don't report which firmware files are getting loaded
* Often no information is reported in regard to firmware files
themselves, such as version, date or firmware file size. In a perfect
world it would be nice to at least see the CRC32 checksum of the
firmware file.
* Often bus and address are not clearly indicated.
* All the required firmware files must be probed simultaneously
(file_exists()) and reported if any of them are missing _before_
attempting to load any of them. For instance missing firmware files
for the amdgpu driver may lead to a system instability or outright crashes.
This needs to change.
What I expect to see in `dmesg`:
module_name: PCI-e 0000:01:00.0 Loading firmware file
'directory/fw1.bin', version 1.2.3, size 12345 bytes
module_name: PCI-e 0000:01:00.0 Loading firmware file
'directory/fw2.bin', version <unversioned>, size 23456 bytes
module_name: PCI-e 0000:01:00.0 Loading firmware file
'directory/fw3.bin', version 1.0.0, size 4444 bytes
In case fw2.bin or fw3.bin is missing, the module must report that info
_before_ attempting to load any found/existing firmware files.
module_name: PCI-e 0000:01:00.0 Warning: missing firmware file
'directory/fw3.bin'
module_name: PCI-e 0000:01:00.0 Warning: missing firmware file
'directory/fw2.bin'
module_name: PCI-e 0000:01:00.0 Loading firmware file
'directory/fw1.bin', version 1.2.3, size 12345 bytes
As it currently stands firmware files are loaded on a one by one basis,
so in case you don't want to keep hundreds of megabytes of useless files
in /lib/firmware, several reboot attempts may be required to figure out
all the missing firmware files which is far from optimal.
Case in point:
cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40),
Revision: B2
cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming
shared reset
cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40),
Revision: B2
cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: xz decompression failed (xz_ret=6)
cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Falling back to default firmware.
No information about firmware being requested whatsoever. No information
about bus or hardware device or maybe there is but it's hard to read.
There's no module named "cs35l41-hda".
Another example:
mt7921e 0000:01:00.0: enabling device (0000 -> 0002)
mt7921e 0000:01:00.0: ASIC revision: 79220010
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20230627143702a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time:
20230627143946
No information about firmware file(s) being loaded whatsoever. Actually
three files are being loaded by this device (Wi-Fi + BlueTooth).
This issue is tracked here:
https://bugzilla.kernel.org/show_bug.cgi?id=217734
Powered by blists - more mailing lists