threeeye
bc1d038eac
Squashed backup commit (no shallow-clone history issues) of xiaomi-mt6833-dev/kernel_xiaomi_mt6833 (lineage-23.2 branch, upstream commit 9eece662e) plus all fixes applied to get everpal_defconfig building clean against a modern (GCC 15.2.0) toolchain -- see the previous commit message on the lineage-23.2 branch (also in this repo history is not available here since this is a squashed snapshot; full incremental history lives in the local DL380 checkout and the upstream GitHub remote). Upstream: https://github.com/xiaomi-mt6833-dev/kernel_xiaomi_mt6833 (lineage-23.2)
31 lines
1.5 KiB
ReStructuredText
31 lines
1.5 KiB
ReStructuredText
========================
|
|
Direct filesystem lookup
|
|
========================
|
|
|
|
Direct filesystem lookup is the most common form of firmware lookup performed
|
|
by the kernel. The kernel looks for the firmware directly on the root
|
|
filesystem in the paths documented in the section 'Firmware search paths'.
|
|
The filesystem lookup is implemented in fw_get_filesystem_firmware(), it
|
|
uses common core kernel file loader facility kernel_read_file_from_path().
|
|
The max path allowed is PATH_MAX -- currently this is 4096 characters.
|
|
|
|
It is recommended you keep /lib/firmware paths on your root filesystem,
|
|
avoid having a separate partition for them in order to avoid possible
|
|
races with lookups and avoid uses of the custom fallback mechanisms
|
|
documented below.
|
|
|
|
Firmware and initramfs
|
|
----------------------
|
|
|
|
Drivers which are built-in to the kernel should have the firmware integrated
|
|
also as part of the initramfs used to boot the kernel given that otherwise
|
|
a race is possible with loading the driver and the real rootfs not yet being
|
|
available. Stuffing the firmware into initramfs resolves this race issue,
|
|
however note that using initrd does not suffice to address the same race.
|
|
|
|
There are circumstances that justify not wanting to include firmware into
|
|
initramfs, such as dealing with large firmware firmware files for the
|
|
remote-proc subsystem. For such cases using a userspace fallback mechanism
|
|
is currently the only viable solution as only userspace can know for sure
|
|
when the real rootfs is ready and mounted.
|