linux/drivers/base/firmware_class.c, branch v3.14

PM / hibernate: Fix restore hang in freeze_processes()

2014-02-26T00:13:15Z

During restore, pm_notifier chain are called with PM_RESTORE_PREPARE. The firmware_class driver handler fw_pm_notify does not have a handler for this. As a result, it keeps a reader on the kmod.c umhelper_sem. During freeze_processes, the call to __usermodehelper_disable tries to take a write lock on this semaphore and hangs waiting. Signed-off-by: Sebastian Capella Acked-by: Ming Lei Cc: All applicable Signed-off-by: Rafael J. Wysocki

firmware_class: Fix the file size check

2014-01-09T04:29:19Z

We expect to read firmware blobs with a single call to kernel_read(), which returns int. Therefore the size must be within the range of int, not long. Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

firmware loader: Add sparse annotation

2014-01-08T23:36:18Z

Avoid that sparse reports the following warning on __fw_free_buf(): drivers/base/firmware_class.c:230:9: warning: context imbalance in '__fw_free_buf' - unexpected unlock Signed-off-by: Bart Van Assche Acked-by: Ming Lei Signed-off-by: Greg Kroah-Hartman

firmware: Suppress fallback warnings when CONFIG_FW_LOADER_USER_HELPER=n

2013-12-09T02:22:33Z

The commit [3e358ac2bb5b: firmware: Be a bit more verbose about direct firmware loading failure] introduced a new warning message about falling back to user helper, but this isn't true when CONFIG_FW_LOADER_USER_HELPER isn't set. In this patch, clear the FW_OPT_FALLBACK flag in the case without userhelper, so that the corresponding code will be disabled. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

firmware: Use bit flags instead of boolean combos

2013-12-09T02:22:32Z

More than two boolean arguments to a function are rather confusing and error-prone for callers. Let's make the behavior bit flags instead of triple combos. A nice suggestion by Borislav Petkov. Acked-by: Borislav Petkov Acked-by: Prarit Bhargava Acked-by: Ming Lei Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

firmware: Introduce request_firmware_direct()

2013-12-09T02:22:32Z

When CONFIG_FW_LOADER_USER_HELPER is set, request_firmware() falls back to the usermode helper for loading via udev when the direct loading fails. But the recent udev takes way too long timeout (60 seconds) for non-existing firmware. This is unacceptable for the drivers like microcode loader where they load firmwares optionally, i.e. it's no error even if no requested file exists. This patch provides a new helper function, request_firmware_direct(). It behaves as same as request_firmware() except for that it doesn't fall back to usermode helper but returns an error immediately if the f/w can't be loaded directly in kernel. Without CONFIG_FW_LOADER_USER_HELPER=y, request_firmware_direct() is just an alias of request_firmware(), due to obvious reason. Tested-by: Prarit Bhargava Acked-by: Ming Lei Acked-by: Borislav Petkov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

firmware: Be a bit more verbose about direct firmware loading failure

2013-09-26T22:35:30Z

The direct firmware loading interface is a bit quiet about failures. Failures that occur during loading are masked if firmware exists in multiple locations, and may be masked entirely in the event that we fall back to the user mode helper code. It would be nice to see some of the more unexpected errors get logged, so in the event that you expect the direct firmware loader to work (like if CONFIG_FW_LOADER_USER_HELPER is enabled), and something goes wrong, you can figure out what happened. Signed-off-by: Neil Horman Acked-by: Ming Lei Signed-off-by: Greg Kroah-Hartman

firmware loader: fix pending_fw_head list corruption

2013-08-30T19:04:27Z

Got the following oops just before reboot: Unable to handle kernel NULL pointer dereference at virtual address 00000000 [<8028d300>] (__list_del_entry+0x44/0xac) [<802e3320>] (__fw_load_abort.part.13+0x1c/0x50) [<802e337c>] (fw_shutdown_notify+0x28/0x50) [<80034f80>] (notifier_call_chain.isra.1+0x5c/0x9c) [<800350ec>] (__blocking_notifier_call_chain+0x44/0x58) [<80035114>] (blocking_notifier_call_chain+0x14/0x18) [<80035d64>] (kernel_restart_prepare+0x14/0x38) [<80035d94>] (kernel_restart+0xc/0x50) The following race condition triggers here: _request_firmware_load() device_create_file(...) kobject_uevent(...) (schedule) (resume) firmware_loading_store(1) firmware_loading_store(0) list_del_init(&buf->pending_list) (schedule) (resume) list_add(&buf->pending_list, &pending_fw_head); wait_for_completion(&buf->completion); causing an oops later when walking pending_list after the firmware has been released. The proposed fix is to move the list_add() before sysfs attribute creation. Signed-off-by: Maxime Bizon Acked-by: Ming Lei Cc: stable Signed-off-by: Greg Kroah-Hartman

driver core: firmware: use __ATTR_RW()

2013-08-24T00:08:48Z

Use __ATTR_RW() instead of __ATTR() to make it more obvious what the type of attribute is being created. Signed-off-by: Greg Kroah-Hartman

firmware loader: fix another compile warning with PM_SLEEP unset

2013-06-26T04:04:22Z

This patch fixes another compiling warning with PM_SLEEP unset: drivers/base/firmware_class.c:221:29: warning: 'fw_lookup_buf' defined but not used [-Wunused-function] This time I do build kernel with both PM_SLEEP set and unset, and no warning found any more with the patch. Reported-by: Stephen Rothwell Signed-off-by: Ming Lei Signed-off-by: Greg Kroah-Hartman