lkml.org 
[lkml]   [2016]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 3/5] firmware: revamp firmware documentation
From
Date
On 12/13/2016 04:08 AM, Luis R. Rodriguez wrote:
> Understanding this code is getting out of control without any
> notes. Give the firmware_class driver a much needed documentation love,
> and while at it convert it to the new sphinx documentation format.

It does help to understand the class/API, thank you!


> +Even if you have these needs there are a few reasons why you may not be
> +able to make use of built-in firmware:
> +
> +* Legalese - firmware is non-GPL compatible
> +* Some firmware may be optional
> +* Firmware upgrades are possible, therefore a new firmware would implicate
> + a complete firmware rebuild.

Could it be you meant "kernel rebuild" or "vmlinux rebuild" here?


> diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> new file mode 100644
> index 000000000000..edce1d76ce29
> --- /dev/null
> +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> @@ -0,0 +1,195 @@
> +===================
> +Fallback mechanisms
> +===================
> +
> +A fallback mechanism is supported to allow to overcome failures to do a direct
> +filesystem lookup on the root filesystem or when the firmware simply cannot be
> +installed for practical reasons on the root filesystem. The kernel
> +configuration options related to supporting the firmware fallback mechanism are:
> +
> + * CONFIG_FW_LOADER_USER_HELPER: enables building the firmware fallback
> + mechanism. Most distributions enable this option today. If enabled but
> + CONFIG_FW_LOADER_USER_HELPER_FALLBACK is disabled, only the custom fallback
> + mechanism is available and for the request_firmware_nowait() call.
> + * CONFIG_FW_LOADER_USER_HELPER_FALLBACK: force enables each request to
> + enable the kobject uevent fallback mechanism on all firmare API calls
> + except request_firmware_direct(). Most distributions disable this option
> + today. The call request_firmware_nowait() allows for one alternative
> + fallback mechanism: if this kconfig option is enabled and your second
> + argument to request_firmware_nowait(), uevent, is set to false you are
> + informing the kernel that you have a custom fallback mechanism and it will
> + manually load the firmware. Read below for more details.

Yeah, it really asks for API simplification ;)

\
 
 \ /
  Last update: 2016-12-13 08:27    [W:0.384 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site