summaryrefslogtreecommitdiff
path: root/drivers/base/firmware_class.c (unfollow)
Commit message (Collapse)Author
2020-05-10firmware: actually return NULL on failed request_firmware_nowait()Brian Norris
commit 715780ae4bb76d6fd2f20eb78e2a9ba9769a6cdc upstream. The kerneldoc for request_firmware_nowait() says that it may call the provided cont() callback with @fw == NULL, if the firmware request fails. However, this is not the case when called with an empty string (""). This case is short-circuited by the 'name[0] == '\0'' check introduced in commit 471b095dfe0d ("firmware_class: make sure fw requests contain a name"), so _request_firmware() never gets to set the fw to NULL. Noticed while using the new 'trigger_async_request' testing hook: # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request [10553.726178] test_firmware: loading '' [10553.729859] test_firmware: loaded: 995209091 # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request [10733.676184] test_firmware: loading '' [10733.679855] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [10733.687951] pgd = ec188000 [10733.690655] [00000004] *pgd=00000000 [10733.694240] Internal error: Oops: 5 [#1] SMP ARM [10733.698847] Modules linked in: btmrvl_sdio btmrvl bluetooth sbs_battery nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables asix usbnet mwifiex_sdio mwifiex cfg80211 jitterentropy_rng drbg joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun [10733.725670] CPU: 0 PID: 6600 Comm: bash Not tainted 4.4.0-rc4-00351-g63d0877 #178 [10733.733137] Hardware name: Rockchip (Device Tree) [10733.737831] task: ed24f6c0 ti: ee322000 task.ti: ee322000 [10733.743222] PC is at do_raw_spin_lock+0x18/0x1a0 [10733.747831] LR is at _raw_spin_lock+0x18/0x1c [10733.752180] pc : [<c00653a0>] lr : [<c054c204>] psr: a00d0013 [10733.752180] sp : ee323df8 ip : ee323e20 fp : ee323e1c [10733.763634] r10: 00000051 r9 : b6f18000 r8 : ee323f80 [10733.768847] r7 : c089cebc r6 : 00000001 r5 : 00000000 r4 : ec0e6000 [10733.775360] r3 : dead4ead r2 : c06bd140 r1 : eef913b4 r0 : 00000000 [10733.781874] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [10733.788995] Control: 10c5387d Table: 2c18806a DAC: 00000051 [10733.794728] Process bash (pid: 6600, stack limit = 0xee322218) [10733.800549] Stack: (0xee323df8 to 0xee324000) [10733.804896] 3de0: ec0e6000 00000000 [10733.813059] 3e00: 00000001 c089cebc ee323f80 b6f18000 ee323e2c ee323e20 c054c204 c0065394 [10733.821221] 3e20: ee323e44 ee323e30 c02fec60 c054c1f8 ec0e7ec0 ec3fcfc0 ee323e5c ee323e48 [10733.829384] 3e40: c02fed08 c02fec48 c07dbf74 eeb05a00 ee323e8c ee323e60 c0253828 c02fecac [10733.837547] 3e60: 00000001 c0116950 ee323eac ee323e78 00000001 ec3fce00 ed2d9700 ed2d970c [10733.845710] 3e80: ee323e9c ee323e90 c02e873c c02537d4 ee323eac ee323ea0 c017bd40 c02e8720 [10733.853873] 3ea0: ee323ee4 ee323eb0 c017b250 c017bd00 00000000 00000000 f3e47a54 ec128b00 [10733.862035] 3ec0: c017b10c ee323f80 00000001 c000f504 ee322000 00000000 ee323f4c ee323ee8 [10733.870197] 3ee0: c011b71c c017b118 ee323fb0 c011bc90 becfa8d9 00000001 ec128b00 00000001 [10733.878359] 3f00: b6f18000 ee323f80 ee323f4c ee323f18 c011bc90 c0063950 ee323f3c ee323f28 [10733.886522] 3f20: c0063950 c0549138 00000001 ec128b00 00000001 ec128b00 b6f18000 ee323f80 [10733.894684] 3f40: ee323f7c ee323f50 c011bed8 c011b6ec c0135fb8 c0135f24 ec128b00 ec128b00 [10733.902847] 3f60: 00000001 b6f18000 c000f504 ee322000 ee323fa4 ee323f80 c011c664 c011be24 [10733.911009] 3f80: 00000000 00000000 00000001 b6f18000 b6e79be0 00000004 00000000 ee323fa8 [10733.919172] 3fa0: c000f340 c011c618 00000001 b6f18000 00000001 b6f18000 00000001 00000000 [10733.927334] 3fc0: 00000001 b6f18000 b6e79be0 00000004 00000001 00000001 8068a3f1 b6e79c84 [10733.935496] 3fe0: 00000000 becfa7dc b6de194d b6e20246 400d0030 00000001 7a4536e8 49bda390 [10733.943664] [<c00653a0>] (do_raw_spin_lock) from [<c054c204>] (_raw_spin_lock+0x18/0x1c) [10733.951743] [<c054c204>] (_raw_spin_lock) from [<c02fec60>] (fw_free_buf+0x24/0x64) [10733.959388] [<c02fec60>] (fw_free_buf) from [<c02fed08>] (release_firmware+0x68/0x74) [10733.967207] [<c02fed08>] (release_firmware) from [<c0253828>] (trigger_async_request_store+0x60/0x124) [10733.976501] [<c0253828>] (trigger_async_request_store) from [<c02e873c>] (dev_attr_store+0x28/0x34) [10733.985533] [<c02e873c>] (dev_attr_store) from [<c017bd40>] (sysfs_kf_write+0x4c/0x58) [10733.993437] [<c017bd40>] (sysfs_kf_write) from [<c017b250>] (kernfs_fop_write+0x144/0x1a8) [10734.001689] [<c017b250>] (kernfs_fop_write) from [<c011b71c>] (__vfs_write+0x3c/0xe4) After this patch: # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request [ 32.126322] test_firmware: loading '' [ 32.129995] test_firmware: failed to async load firmware -bash: printf: write error: No such device Fixes: 471b095dfe0d ("firmware_class: make sure fw requests contain a name") Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Ming Lei <ming.lei@canonical.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-17firmware_class: make firmware caching configurableTim Murray
Because firmware caching generates uevent messages that are sent over a netlink socket, it can prevent suspend on many platforms. It's also not always useful, so make it a configurable option. bug 32180327 Change-Id: I1250512b27edb56caa78d536e5ccf1fb669476ad Signed-off-by: Tim Murray <timmurray@google.com> Git-repo: https://source.codeaurora.org/quic/la/kernel/msm-4.4 Git-commit: e3198d51be98ec5606e2a2c5112a8a974d354fbc Signed-off-by: Chintan Pandya <cpandya@codeaurora.org> Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
2017-06-26 base: firmware: add /lib64/firmware to firmware loading pathBharathraj Nagaraju
Adding /lib64/firmware to the driver for loading firmware from the target. Change-Id: I1e489efc7e0d56991a0671950b88ce15afe3825b Signed-off-by: Bharathraj Nagaraju <snbraj@codeaurora.org>
2017-06-13firmware_class: Avoid memory leak when FW_OPT_NOCACHE is setGaurav Kohli
During call of request_firmware_into_buf, if FW_OPT_NOCACHE is set then release_firmware skip freeing of fw_id. So explicitly freeing the same to avoid memory leak. Change-Id: I7e1d6f8f06c4532b2bcbf256267fd1e90f5ced70 Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org>
2017-05-04firmware_class: Avoid pending list corruptionImran Khan
Remove firmware buffer from pending list when it is freed. Once the buffer is free kmalloc can allocate the same slab object for some other user but as the buffer is still there in the pending list, we end up with multiple users of the same slab object using it in different contexts. Change-Id: Id83afbd4416a82646f46b5015d983b9c63a2a613 Signed-off-by: Imran Khan <kimran@codeaurora.org>
2017-02-27Revert "firmware_class: Add an additional path to fw_path list"Satya Durga Srinivasu Prabhala
This reverts commit 3e47c536248f ("firmware_class: Add an additional path to fw_path list"). Adding /firmware/images entry in fw_path is introducing selinux denials as the access was happening under the client process context. Removing the entry from fw_path structure. Change-Id: I359f8defe49595a7e53558992080cb94eba42451 Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
2017-02-13firmware_class: Add null check in firmware_direct_writePrasad Sodagudi
Add null check in firmware_direct_write to avoid null pointer dereference due to firmware_abort. Change-Id: Ibde30452bb6f3fe7a9f92aa3b1f2ed85a858d94e Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
2017-01-09firmware: fix usermode helper fallback loadingYves-Alexis Perez
commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 upstream. When you use the firmware usermode helper fallback with a timeout value set to a value greater than INT_MAX (2147483647) a cast overflow issue causes the timeout value to go negative and breaks all usermode helper loading. This regression was introduced through commit 68ff2a00dbf5 ("firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()") on kernel v4.0. The firmware_class drivers relies on the firmware usermode helper fallback as a mechanism to look for firmware if the direct filesystem search failed only if: a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros): Then all of these callers will rely on the fallback mechanism in case the firmware is not found through an initial direct filesystem lookup: o request_firmware() o request_firmware_into_buf() o request_firmware_nowait() b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros): Then only callers using request_firmware_nowait() with the second argument set to false, this explicitly is requesting the UMH firmware fallback to be relied on in case the first filesystem lookup fails. Using Coccinelle SmPL grammar we have identified only two drivers explicitly requesting the UMH firmware fallback mechanism: - drivers/firmware/dell_rbu.c - drivers/leds/leds-lp55xx-common.c Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the biggest impact of this regression are users of the dell_rbu and leds-lp55xx-common device driver which required the UMH to find their respective needed firmwares. The default timeout for the UMH is set to 60 seconds always, as of commit 68ff2a00dbf5 ("firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()") the timeout was bumped to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET value was also used if the timeout was configured by a user to 0. The following works: echo 2147483647 > /sys/class/firmware/timeout But both of the following set the timeout to MAX_JIFFY_OFFSET even if we display 0 back to userspace: echo 2147483648 > /sys/class/firmware/timeout cat /sys/class/firmware/timeout 0 echo 0> /sys/class/firmware/timeout cat /sys/class/firmware/timeout 0 A max value of INT_MAX (2147483647) seconds is therefore implicit due to the another cast with simple_strtol(). This fixes the secondary cast (the first one is simple_strtol() but its an issue only by forcing an implicit limit) by re-using the timeout variable and only setting retval in appropriate cases. Lastly worth noting systemd had ripped out the UMH firmware fallback mechanism from udev since udev 2014 via commit be2ea723b1d023b3d ("udev: remove userspace firmware loading support"), so as of systemd v217. Signed-off-by: Yves-Alexis Perez <corsac@corsac.net> Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()" Cc: Luis R. Rodriguez <mcgrof@kernel.org> Cc: Ming Lei <ming.lei@canonical.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Luis R. Rodriguez <mcgrof@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> [mcgrof@kernel.org: gave commit log a whole lot of love] Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-12firmware_class: Add missing change during kernel upgradeGaurav Kohli
Add missing change for request_firmware_nowait so third party drivers are able to load their firmware Change-Id: Ic6b842a717bde9c2bc50a7c7845c7c50ac05be25 Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org>
2016-03-23firmware_class: fix direct firmware loading API supportDavid Keitel
The direct firmware class API support original relied on the destination address to determine which file operations to link to the data binary file. Since the 4.4 kernel version, this was changed to an attribute group. Fix this by adding a direct firmware API attribute group and appropriately assign it when necessary. Signed-off-by: David Keitel <dkeitel@codeaurora.org>
2016-03-22firmware_class: Don't fail request_firmware if we're not using a bufferVikram Mulukutla
A check that the intermediate firmware actually contains data is performed before returning from request_firmware. Perform this check only if we're actually using the intermediate buffer. Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
2016-03-22firmware_class: Add an additional path to fw_path listDeepak Katragadda
Add an additional path, /firmware/image to the list of fw paths that request_firmware looks into for the firmware images. Change-Id: I4b9164f222bf0a8546072de97838bf9d49dd8252 Signed-off-by: Deepak Katragadda <dkatraga@codeaurora.org>
2016-03-22firmware_class: Change print levels for some warningsDeepak Katragadda
Currently, when _request_firmware() fails to find the firmware from the default /lib location, a couple of error messages are printed denoting the same. Change the print level for these messages from dev_warn to dev_dbg as it is fairly common to have the user-space helper loading the firmware for us. Change-Id: I5e06b3785f58e85eda45d32130b9acbc75cd2c0a Signed-off-by: Deepak Katragadda <dkatraga@codeaurora.org> [vmulukut: adjusted for upstream changes] Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
2016-03-22firmware_class: Correct a null check in firmware_direct_readVikram Mulukutla
Don't use the fw pointer before performing the null check on it. Change-Id: I303f71681647e2acb0b7e340b8f8580436cfb19d Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
2016-03-22firmware_class: Include a size argument in unmap_fw_memVikram Mulukutla
Some implementations may need to know the size of a region allocated by map_fw_mem in the context of the unmap_fw_mem callback. Add this as an argument to the callback signature. Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
2016-03-22firmware_class: Allow private data in [unmap|map]_fw_memVikram Mulukutla
Some callers of request_firmware_direct may need additional context to be able to map firmware memory. Allow private data to be passed in with request_firmware_direct, and send this data along with the [unmap|map]_fw_mem callbacks. Change-Id: I05a15eb46cc663a4476b784e30e80182a28e10c3 Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org> [joshc: dropped PIL portions, fixed trivial conflict in firmware.h due to API rename] Signed-off-by: Josh Cartwright <joshc@codeaurora.org> [vmulukut: adjusted for upstream merge conflicts] Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
2016-03-22firmware_class: Introduce the request_firmware_direct APIVikram Mulukutla
On devices with low memory, using request_firmware on rather large firmware images results in a memory usage penalty that might be unaffordable. Introduce a new API that allows the firmware image to be directly loaded to a destination address without using any intermediate buffer. Change-Id: I51b55dd9044ea669e2126a3f908028850bf76325 Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org> [joshc: renamed request_firmware_direct to request_firmware_into_buf, avoiding namespace conflict] Signed-off-by: Josh Cartwright <joshc@codeaurora.org> [vmulukut: upstream merge conflict fixups] Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org> [dkeitel: upstream merge conflict fixups] Signed-off-by: David Keitel <dkeitel@codeaurora.org>
2016-03-22firmware_class: Provide infrastructure to make fw caching optionalVikram Mulukutla
Some low memory systems with complex peripherals cannot afford to have the relatively large firmware images taking up valuable memory during suspend and resume. Change the internal implementation of firmware_class to disallow caching based on a configurable option. In the near future, variants of request_firmware will take advantage of this configurability. Change-Id: I44be7ce3b308b642fb018086def99fcb800a1109 Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org> [joshc: reworked to use opt_flags instead of 'nocache' bool in fw_desc] Signed-off-by: Josh Cartwright <joshc@codeaurora.org> [vmulukut: adjusted for upstream additions to opt_flags] Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
2016-03-22firmware_class: Introduce a firmware descriptor structureVikram Mulukutla
Introduce a firmware descriptor structure that makes it easier to pass around various configuration options in the internal implementation of firmware_class. Change-Id: I5c1da222bccd568fabb26da5baccaa4035331efd Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org> [joshc: reworked to make use of upstream's opt_flags member] Signed-off-by: Josh Cartwright <joshc@codeaurora.org> [vmulukut: adjusted for upstream changes to opt_flags] Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org> [dkeitel: resolved merge conflicts] Signed-off-by: David Keitel <dkeitel@codeaurora.org>
2015-08-05firmware: fix wrong memory deallocation in fw_add_devm_name()Vladimir Zapolskiy
Device resource data allocated with devres_alloc() must be deallocated by devres_free(). Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Acked-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-07-09Fix firmware loader uevent buffer NULL pointer dereferenceLinus Torvalds
The firmware class uevent function accessed the "fw_priv->buf" buffer without the proper locking and testing for NULL. This is an old bug (looks like it goes back to 2012 and commit 1244691c73b2: "firmware loader: introduce firmware_buf"), but for some reason it's triggering only now in 4.2-rc1. Shuah Khan is trying to bisect what it is that causes this to trigger more easily, but in the meantime let's just fix the bug since others are hitting it too (at least Ingo reports having seen it as well). Reported-and-tested-by: Shuah Khan <shuahkh@osg.samsung.com> Acked-by: Ming Lei <ming.lei@canonical.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-06-01firmware: add missing kfree for work on async callLuis R. Rodriguez
The recent fix to use kstrdup_const() failed to add a kfree upon failure of name allocation... Cc: Ming Lei <ming.lei@canonical.com> Cc: Seth Forshee <seth.forshee@canonical.com> Cc: Kyle McMartin <kyle@kernel.org> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-24firmware: use const for remaining firmware namesLuis R. Rodriguez
We currently use flexible arrays with a char at the end for the remaining internal firmware name uses. There are two limitations with the way we use this. Since we're using a flexible array for a string on the struct if we wanted to use two strings it means we'd have a disjoint means of handling the strings, one using the flexible array, and another a char * pointer. We're also currently not using 'const' for the string. We wish to later extend some firmware data structures with other string/char pointers, but we also want to be very pedantic about const usage. Since we're going to change things to use 'const' we might as well also address unified way to use multiple strings on the structs. Replace the flexible array practice for strings with kstrdup_const() and kfree_const(), this will avoid allocations when the vmlinux .rodata is used, and just allocate a new proper string for us when needed. This also means we can simplify the struct allocations by removing the string length from the allocation size computation, which would otherwise get even more complicated when supporting multiple strings. Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: David Howells <dhowells@redhat.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Seth Forshee <seth.forshee@canonical.com> Cc: Kyle McMartin <kyle@kernel.org> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-24firmware: fix possible use after free on name on asynchronous requestLuis R. Rodriguez
Asynchronous firmware loading copies the pointer to the name passed as an argument only to be scheduled later and used. This behaviour works well for synchronous calling but in asynchronous mode there's a chance the caller could immediately free the passed string after making the asynchronous call. This could trigger a use after free having the kernel look on disk for arbitrary file names. In order to force-test the issue you can use a test-driver designed to illustrate this issue on github [0], use the next-20150505-fix-use-after-free branch. With this patch applied you get: [ 283.512445] firmware name: test_module_stuff.bin [ 287.514020] firmware name: test_module_stuff.bin [ 287.532489] firmware found Without this patch applied you can end up with something such as: [ 135.624216] firmware name: \xffffff80BJ [ 135.624249] platform fake-dev.0: Direct firmware load for \xffffff80Bi failed with error -2 [ 135.624252] No firmware found [ 135.624252] firmware found Unfortunatley in the worst and most common case however you can typically crash your system with a page fault by trying to free something which you cannot, and/or a NULL pointer dereference [1]. The fix and issue using schedule_work() for asynchronous runs is generalized in the following SmPL grammar patch, when applied to next-20150505 only the firmware_class code is affected. This grammar patch can and should further be generalized to vet for for other kernel asynchronous mechanisms. @ calls_schedule_work @ type T; T *priv_work; identifier func, work_func; identifier work; identifier priv_name, name; expression gfp; @@ func(..., const char *name, ...) { ... priv_work = kzalloc(sizeof(T), gfp); ... - priv_work->priv_name = name; + priv_work->priv_name = kstrdup_const(name, gfp); ... (... when any if (...) { ... + kfree_const(priv_work->priv_name); kfree(priv_work); ... } ) ... when any INIT_WORK(&priv_work->work, work_func); ... schedule_work(&priv_work->work); ... } @ the_work_func depends on calls_schedule_work @ type calls_schedule_work.T; T *priv_work; identifier calls_schedule_work.work_func; identifier calls_schedule_work.priv_name; identifier calls_schedule_work.work; identifier some_work; @@ work_func(...) { ... priv_work = container_of(some_work, T, work); ... + kfree_const(priv_work->priv_name); kfree(priv_work); ... } [0] https://github.com/mcgrof/fake-firmware-test.git [1] The following kernel ring buffer splat: firmware name: test_module_stuff.bin firmware name: firmware found general protection fault: 0000 [#1] SMP Modules linked in: test(O) <...etc-it-does-not-matter> drm sr_mod cdrom xhci_pci xhci_hcd rtsx_pci mfd_core video button sg CPU: 3 PID: 87 Comm: kworker/3:2 Tainted: G O 4.0.0-00010-g22b5bb0-dirty #176 Hardware name: LENOVO 20AW000LUS/20AW000LUS, BIOS GLET43WW (1.18 ) 12/04/2013 Workqueue: events request_firmware_work_func task: ffff8800c7f8e290 ti: ffff8800c7f94000 task.ti: ffff8800c7f94000 RIP: 0010:[<ffffffff814a586c>] [<ffffffff814a586c>] fw_free_buf+0xc/0x40 RSP: 0000:ffff8800c7f97d78 EFLAGS: 00010286 RAX: ffffffff81ae3700 RBX: ffffffff816d1181 RCX: 0000000000000006 RDX: 0001ee850ff68500 RSI: 0000000000000246 RDI: c35d5f415e415d41 RBP: ffff8800c7f97d88 R08: 000000000000000a R09: 0000000000000000 R10: 0000000000000358 R11: ffff8800c7f97a7e R12: ffff8800c7ec1e80 R13: ffff88021e2d4cc0 R14: ffff88021e2dff00 R15: 00000000000000c0 FS: 0000000000000000(0000) GS:ffff88021e2c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000034b8cd8 CR3: 000000021073c000 CR4: 00000000001407e0 Stack: ffffffff816d1181 ffff8800c7ec1e80 ffff8800c7f97da8 ffffffff814a58f8 000000000000000a ffffffff816d1181 ffff8800c7f97dc8 ffffffffa047002c ffff88021e2dff00 ffff8802116ac1c0 ffff8800c7f97df8 ffffffff814a65fe Call Trace: [<ffffffff816d1181>] ? __schedule+0x361/0x940 [<ffffffff814a58f8>] release_firmware+0x58/0x80 [<ffffffff816d1181>] ? __schedule+0x361/0x940 [<ffffffffa047002c>] test_mod_cb+0x2c/0x43 [test] [<ffffffff814a65fe>] request_firmware_work_func+0x5e/0x80 [<ffffffff816d1181>] ? __schedule+0x361/0x940 [<ffffffff8108d23a>] process_one_work+0x14a/0x3f0 [<ffffffff8108d911>] worker_thread+0x121/0x460 [<ffffffff8108d7f0>] ? rescuer_thread+0x310/0x310 [<ffffffff810928f9>] kthread+0xc9/0xe0 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180 [<ffffffff816d52d8>] ret_from_fork+0x58/0x90 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180 Code: c7 c6 dd ad a3 81 48 c7 c7 20 97 ce 81 31 c0 e8 0b b2 ed ff e9 78 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 54 53 <4c> 8b 67 38 48 89 fb 4c 89 e7 e8 85 f7 22 00 f0 83 2b 01 74 0f RIP [<ffffffff814a586c>] fw_free_buf+0xc/0x40 RSP <ffff8800c7f97d78> ---[ end trace 4e62c56a58d0eac1 ]--- BUG: unable to handle kernel paging request at ffffffffffffffd8 IP: [<ffffffff81093ee0>] kthread_data+0x10/0x20 PGD 1c13067 PUD 1c15067 PMD 0 Oops: 0000 [#2] SMP Modules linked in: test(O) <...etc-it-does-not-matter> drm sr_mod cdrom xhci_pci xhci_hcd rtsx_pci mfd_core video button sg CPU: 3 PID: 87 Comm: kworker/3:2 Tainted: G D O 4.0.0-00010-g22b5bb0-dirty #176 Hardware name: LENOVO 20AW000LUS/20AW000LUS, BIOS GLET43WW (1.18 ) 12/04/2013 task: ffff8800c7f8e290 ti: ffff8800c7f94000 task.ti: ffff8800c7f94000 RIP: 0010:[<ffffffff81092ee0>] [<ffffffff81092ee0>] kthread_data+0x10/0x20 RSP: 0018:ffff8800c7f97b18 EFLAGS: 00010096 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 000000000000000d RDX: 0000000000000003 RSI: 0000000000000003 RDI: ffff8800c7f8e290 RBP: ffff8800c7f97b18 R08: 000000000000bc00 R09: 0000000000007e76 R10: 0000000000000001 R11: 000000000000002f R12: ffff8800c7f8e290 R13: 00000000000154c0 R14: 0000000000000003 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88021e2c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000210675000 CR4: 00000000001407e0 Stack: ffff8800c7f97b38 ffffffff8108dcd5 ffff8800c7f97b38 ffff88021e2d54c0 ffff8800c7f97b88 ffffffff816d1500 ffff880213d42368 ffff8800c7f8e290 ffff8800c7f97b88 ffff8800c7f97fd8 ffff8800c7f8e710 0000000000000246 Call Trace: [<ffffffff8108dcd5>] wq_worker_sleeping+0x15/0xa0 [<ffffffff816d1500>] __schedule+0x6e0/0x940 [<ffffffff816d1797>] schedule+0x37/0x90 [<ffffffff810779bc>] do_exit+0x6bc/0xb40 [<ffffffff8101898f>] oops_end+0x9f/0xe0 [<ffffffff81018efb>] die+0x4b/0x70 [<ffffffff81015622>] do_general_protection+0xe2/0x170 [<ffffffff816d74e8>] general_protection+0x28/0x30 [<ffffffff816d1181>] ? __schedule+0x361/0x940 [<ffffffff814a586c>] ? fw_free_buf+0xc/0x40 [<ffffffff816d1181>] ? __schedule+0x361/0x940 [<ffffffff814a58f8>] release_firmware+0x58/0x80 [<ffffffff816d1181>] ? __schedule+0x361/0x940 [<ffffffffa047002c>] test_mod_cb+0x2c/0x43 [test] [<ffffffff814a65fe>] request_firmware_work_func+0x5e/0x80 [<ffffffff816d1181>] ? __schedule+0x361/0x940 [<ffffffff8108d23a>] process_one_work+0x14a/0x3f0 [<ffffffff8108d911>] worker_thread+0x121/0x460 [<ffffffff8108d7f0>] ? rescuer_thread+0x310/0x310 [<ffffffff810928f9>] kthread+0xc9/0xe0 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180 [<ffffffff816d52d8>] ret_from_fork+0x58/0x90 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180 Code: 00 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 87 30 05 00 00 55 48 89 e5 <48> 8b 40 d8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 RIP [<ffffffff81092ee0>] kthread_data+0x10/0x20 RSP <ffff8800c7f97b18> CR2: ffffffffffffffd8 ---[ end trace 4e62c56a58d0eac2 ]--- Fixing recursive fault but reboot is needed! Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: David Howells <dhowells@redhat.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Seth Forshee <seth.forshee@canonical.com> Cc: Kyle McMartin <kyle@kernel.org> Generated-by: Coccinelle SmPL Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-24firmware: check for file truncation on direct firmware loadingLuis R. Rodriguez
When direct firmware loading is used we iterate over a list of possible firmware paths and concatenate the desired firmware name with each path and look for the file there. Should the passed firmware name be too long we end up truncating the file we want to look for, the search however is still done. Add a check for truncation instead of looking for a truncated firmware filename. Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Ming Lei <ming.lei@canonical.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: David Howells <dhowells@redhat.com> Cc: Kyle McMartin <kyle@kernel.org> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-24firmware: fix __getname() missing failure checkLuis R. Rodriguez
The request_firmware*() APIs uses __getname() to iterate over the list of paths possible for firmware to be found, the code however never checked for failure on __getname(). Although *very unlikely*, this can still happen. Add the missing check. There is still no checks on the concatenation of the path and filename passed, that requires a bit more work and subsequent patches address this. The commit that introduced this is abb139e7 ("firmware: teach the kernel to load firmware files directly from the filesystem"). mcgrof@ergon ~/linux (git::firmware-fixes) $ git describe --contains abb139e7 v3.7-rc1~120 Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Ming Lei <ming.lei@canonical.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: David Howells <dhowells@redhat.com> Cc: Kyle McMartin <kyle@kernel.org> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-25drivers: base: fw: fix ret value when loading fwZahari Doychev
When using the user mode helper to load firmwares the function _request_firmware gets a positive return value from fw_load_from_user_helper and because of this the firmware buffer is not assigned. This happens only when the return value is zero. This patch fixes this problem in _request_firmware_load. When the completion is ready the return value is set to zero. Signed-off-by: Zahari Doychev <zahari.doychev@linux.com> Cc: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-25firmware: Avoid manual device_create_file() callsTakashi Iwai
Use the static attribute groups assigned to the device instead of manual device_create_file() & co calls. It simplifies the code and can avoid possible races, too. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-25firmware_class: Fix whitespace and indentationAndrei Oprea
Fix checkpatch.pl issues with coding style. Removed whitespace and fixed indentation Signed-off-by: Andrei Oprea <andrei.br92@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-02-12PM / OPP / clk: Remove unnecessary OOM messageQuentin Lambert
This patch reduces the kernel size by removing error messages that duplicate the normal OOM message. A simplified version of the semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr) @@ identifier f,print,l; expression e; constant char[] c; @@ e = \(kzalloc\|kmalloc\|devm_kzalloc\|devm_kmalloc\)(...); if (e == NULL) { <+... - print(...,c,...); ... when any ( goto l; | return ...; ) ...+> } Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-03firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()Ming Lei
It is simpler to handle timeout by wait_for_completion_interruptible_timeout(), so remove previous delay work for timeout. Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-02-03firmware_loader: abort request if wait_for_completion is interruptedMing Lei
If current request is interrupted by signal, such as 'ctrl + c', this request has to be aborted for the following reasons: - the buf need to be removed from pending list - same requests from other contexts need to be completed Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-02-03firmware: Correct function name in commentBorislav Petkov
Use the correct function name in the kernel-doc comment above it. Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-26firmware class: Deletion of an unnecessary check before the function call ↵Markus Elfring
"vunmap" The vunmap() function performes also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-26firmware loader: fix hung task warning dumpKweh, Hock Leong
When using request_firmware_nowait() with FW_ACTION_NOHOTPLUG param to expose user helper interface, if the user do not react immediately, after 120 seconds there will be a hung task warning message dumped as below: [ 3000.784235] INFO: task kworker/0:0:8259 blocked for more than 120 seconds. [ 3000.791281] Tainted: G E 3.16.0-rc1-yocto-standard #41 [ 3000.798082] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 3000.806072] kworker/0:0 D cd0075c8 0 8259 2 0x00000000 [ 3000.812765] Workqueue: events request_firmware_work_func [ 3000.818253] cd375e18 00000046 0000000e cd0075c8 000000f0 cd40ea00 cd375fec 1b883e89 [ 3000.826374] 0000026b cd40ea00 80000000 00000001 cd0075c8 00000000 cd375de4 c119917f [ 3000.834492] cd563360 cd375df4 c119a0ab cd563360 00000000 cd375e24 c119a1d6 00000000 [ 3000.842616] Call Trace: [ 3000.845252] [<c119917f>] ? kernfs_next_descendant_post+0x3f/0x50 [ 3000.851543] [<c119a0ab>] ? kernfs_activate+0x6b/0xc0 [ 3000.856790] [<c119a1d6>] ? kernfs_add_one+0xd6/0x130 [ 3000.862047] [<c15fdb02>] schedule+0x22/0x60 [ 3000.866548] [<c15fd195>] schedule_timeout+0x175/0x1d0 [ 3000.871887] [<c119b391>] ? __kernfs_create_file+0x71/0xa0 [ 3000.877574] [<c119bb9a>] ? sysfs_add_file_mode_ns+0xaa/0x180 [ 3000.883533] [<c15fe84f>] wait_for_completion+0x6f/0xb0 [ 3000.888961] [<c1065200>] ? wake_up_process+0x40/0x40 [ 3000.894219] [<c13cb600>] _request_firmware+0x750/0x9f0 [ 3000.899666] [<c1382a7f>] ? n_tty_receive_buf2+0x1f/0x30 [ 3000.905200] [<c13cba02>] request_firmware_work_func+0x22/0x50 [ 3000.911235] [<c10550d2>] process_one_work+0x122/0x380 [ 3000.916571] [<c1055859>] worker_thread+0xf9/0x470 [ 3000.921555] [<c1055760>] ? create_and_start_worker+0x50/0x50 [ 3000.927497] [<c1055760>] ? create_and_start_worker+0x50/0x50 [ 3000.933448] [<c105a5ff>] kthread+0x9f/0xc0 [ 3000.937850] [<c15ffd40>] ret_from_kernel_thread+0x20/0x30 [ 3000.943548] [<c105a560>] ? kthread_worker_fn+0x100/0x100 This patch change the wait_for_completion() function call to wait_for_completion_interruptible() function call for solving the issue. Cc: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com> Acked-by: Ming Lei <ming.lei@canonical.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-23firmware_class: make sure fw requests contain a nameKees Cook
An empty firmware request name will trigger warnings when building device names. Make sure this is caught earlier and rejected. The warning was visible via the test_firmware.ko module interface: echo -ne "\x00" > /sys/devices/virtual/misc/test_firmware/trigger_request Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Tested-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-25firmware_class: perform new LSM checksKees Cook
This attaches LSM hooks to the existing firmware loading interfaces: filesystem-found firmware and demand-loaded blobs. On errors, loads are aborted and the failure code is returned to userspace. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Takashi Iwai <tiwai@suse.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-23firmware loader: Fix _request_firmware_load() return val for fw load abortShuah Khan
_request_firmware_load() returns -ENOMEM when fw load is aborted after timeout. Call is_fw_load_aborted() to check if fw load is aborted and if true return -EAGAIN. Signed-off-by: Shuah Khan <shuah.kh@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-08firmware loader: inform direct failure when udev loader is disabledLuis R. Rodriguez
Now that the udev firmware loader is optional request_firmware() will not provide any information on the kernel ring buffer if direct firmware loading failed and udev firmware loading is disabled. If no information is needed request_firmware_direct() should be used for optional firmware, at which point drivers can take on the onus over informing of any failures, if udev firmware loading is disabled though we should at the very least provide some sort of information as when the udev loader was enabled by default back in the days. With this change with a simple firmware load test module [0]: Example output without FW_LOADER_USER_HELPER_FALLBACK platform fake-dev.0: Direct firmware load for fake.bin failed with error -2 Example with FW_LOADER_USER_HELPER_FALLBACK platform fake-dev.0: Direct firmware load for fake.bin failed with error -2 platform fake-dev.0: Falling back to user helper Without this change without FW_LOADER_USER_HELPER_FALLBACK we get no output logged upon failure. Cc: Tom Gundersen <teg@jklm.no> Cc: Ming Lei <ming.lei@canonical.com> Cc: Abhay Salunke <Abhay_Salunke@dell.com> Cc: Stefan Roese <sr@denx.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kay Sievers <kay@vrfy.org> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-08firmware: replace ALIGN(PAGE_SIZE) by PAGE_ALIGNFabian Frederick
use mm.h definition Cc: Ming Lei <ming.lei@canonical.com> Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-08firmware: read firmware size using i_size_read()Dmitry Kasatkin
There is no need to read attr because inode structure contains size of the file. Use i_size_read() instead. Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Acked-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-08firmware loader: allow disabling of udev as firmware loaderTakashi Iwai
[The patch was originally proposed by Tom Gundersen, and rewritten afterwards by me; most of changelogs below borrowed from Tom's original patch -- tiwai] Currently (at least) the dell-rbu driver selects FW_LOADER_USER_HELPER, which means that distros can't really stop loading firmware through udev without breaking other users (though some have). Ideally we would remove/disable the udev firmware helper in both the kernel and in udev, but if we were to disable it in udev and not the kernel, the result would be (seemingly) hung kernels as no one would be around to cancel firmware requests. This patch allows udev firmware loading to be disabled while still allowing non-udev firmware loading, as done by the dell-rbu driver, to continue working. This is achieved by only using the fallback mechanism when the uevent is suppressed. The patch renames the user-selectable Kconfig from FW_LOADER_USER_HELPER to FW_LOADER_USER_HELPER_FALLBACK, and the former is reverse-selected by the latter or the drivers that need userhelper like dell-rbu. Also, the "default y" is removed together with this change, since it's been deprecated in udev upstream, thus rather better to disable it nowadays. Tested with FW_LOADER_USER_HELPER=n LATTICE_ECP3_CONFIG=y DELL_RBU=y and udev without the firmware loading support, but I don't have the hardware to test the lattice/dell drivers, so additional testing would be appreciated. Reviewed-by: Tom Gundersen <teg@jklm.no> Cc: Ming Lei <ming.lei@canonical.com> Cc: Abhay Salunke <Abhay_Salunke@dell.com> Cc: Stefan Roese <sr@denx.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kay Sievers <kay@vrfy.org> Tested-by: Balaji Singh <B_B_Singh@DELL.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-26PM / hibernate: Fix restore hang in freeze_processes()Sebastian Capella
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 <sebastian.capella@linaro.org> Acked-by: Ming Lei <ming.lei@canonical.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-15firmware: use power efficient workqueue for unloading and aborting fw loadShaibal Dutta
Allow the scheduler to select the most appropriate CPU for running the firmware load timeout routine and delayed routine for firmware unload. This extends idle residency times and conserves power. This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected. Cc: Ming Lei <ming.lei@canonical.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com> [zoran.markovic@linaro.org: Rebased to latest kernel, added commit message. Fixed code alignment.] Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-15firmware: give a protection when map page failedzhang jun
so, we need give a protection and return a error value. [ 7341.474236] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive unpin_work! [ 7341.494464] atomisp-css2400b0_v21 0000:00:03.0: unhandled css stored event: 0x20 [ 7341.503627] vmap allocation for size 208896 failed: use vmalloc=<size> to increase size.<=================== map failed [ 7341.507135] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive unpin_work! [ 7341.503848] BUG: unable to handle kernel NULL pointer dereference at (null) [ 7341.520394] IP: [<c18f5c1b>] sst_load_all_modules_elf+0x1bb/0x850 [ 7341.527216] *pdpt = 0000000030dfe001 *pde = 0000000000000000 [ 7341.533640] Oops: 0000 [#1] PREEMPT SMP [ 7341.540360] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive unpin_work! [ 7341.538037] Modules linked in: atomisp_css2400b0_v21 lm3554 ov2722 imx1x5 atmel_mxt_ts vxd392 videobuf_vmalloc videobuf_core lm_dump(O) bcm_bt_lpm hdmi_audio bcm4334x(O) [ 7341.563531] CPU: 1 PID: 525 Comm: mediaserver Tainted: G W O 3.10.20-262518-ga83c053 #1 [ 7341.573253] task: f0994ec0 ti: f09f0000 task.ti: f09f0000 [ 7341.579284] EIP: 0060:[<c18f5c1b>] EFLAGS: 00010246 CPU: 1 [ 7341.585415] EIP is at sst_load_all_modules_elf+0x1bb/0x850 [ 7341.591541] EAX: 00000000 EBX: e3595ba0 ECX: 00000000 EDX: 00031c1c [ 7341.598541] ESI: e04a0000 EDI: 00000000 EBP: f09f1d80 ESP: f09f1cf4 [ 7341.605542] DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068 [ 7341.611573] CR0: 80050033 CR2: 00000000 CR3: 30db4000 CR4: 001007f0 [ 7341.618573] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 7341.625575] DR6: ffff0ff0 DR7: 00000400 [ 7341.629856] Stack: [ 7341.632097] f09f1d57 00000019 c1d656d7 c1d658d3 c1d56409 00000f28 c1d64af9 18000103 [ 7341.640766] 01000001 00080000 c1f910a0 f326f4c8 00000034 f326f520 00000002 e04a02bc [ 7341.649465] 00000001 f326e014 c1f910b0 e04a0000 c0080100 00031c1c e3595ba0 c0080100 [ 7341.658149] Call Trace: [ 7341.660888] [<c18f6308>] sst_post_download_byt+0x58/0xb0 [ 7341.666925] [<c18f4fbc>] sst_load_fw+0xdc/0x510 [ 7341.672086] [<c1a7b2c0>] ? __mutex_lock_slowpath+0x250/0x370 [ 7341.678507] [<c1a80e05>] ? sub_preempt_count+0x55/0xe0 [ 7341.684346] [<c18f1294>] sst_download_fw+0x14/0x60 [ 7341.689796] [<c1a7b403>] ? mutex_lock+0x23/0x30 [ 7341.694954] [<c18f191c>] intel_sst_check_device+0x6c/0x120 [ 7341.701181] [<c18f1d08>] sst_set_generic_params+0x1b8/0x4a0 [ 7341.707504] [<c1a80e05>] ? sub_preempt_count+0x55/0xe0 [ 7341.713341] [<c1a80e05>] ? sub_preempt_count+0x55/0xe0 [ 7341.719178] [<c1a7b2c0>] ? __mutex_lock_slowpath+0x250/0x370 [ 7341.725600] [<c1320d84>] ? __kmalloc_track_caller+0xe4/0x1d0 [ 7341.732022] [<c18e35f5>] sst_set_mixer_param+0x25/0x40 [ 7341.737859] [<c18e3853>] lpe_mixer_ihf_set+0xb3/0x160 [ 7341.743602] [<c1855b99>] snd_ctl_ioctl+0xa89/0xb40 [ 7341.749052] [<c1331e65>] ? path_openat+0xa5/0x3d0 [ 7341.754409] [<c1447857>] ? avc_has_perm_flags+0xc7/0x170 [ 7341.760441] [<c1855110>] ? snd_ctl_elem_add_user+0x540/0x540 [ 7341.766862] [<c1334047>] do_vfs_ioctl+0x77/0x5e0 [ 7341.772117] [<c144842a>] ? inode_has_perm.isra.42.constprop.79+0x3a/0x50 [ 7341.779705] [<c14490a0>] ? file_has_perm+0xa0/0xb0 [ 7341.785155] [<c14493b8>] ? selinux_file_ioctl+0x48/0xe0 [ 7341.791090] [<c1334628>] SyS_ioctl+0x78/0x90 [ 7341.795958] [<c1a7dde8>] syscall_call+0x7/0xb [ 7341.800925] [<c1a70000>] ? mm_fault_error+0x13c/0x198 Signed-off-by: zhang jun <jun.zhang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-08firmware_class: Fix the file size checkBen Hutchings
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 <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-08firmware loader: Add sparse annotationBart Van Assche
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 <bvanassche@acm.org> Acked-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-08firmware: Suppress fallback warnings when CONFIG_FW_LOADER_USER_HELPER=nTakashi Iwai
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 <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-08firmware: Use bit flags instead of boolean combosTakashi Iwai
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 <bp@suse.de> Acked-by: Prarit Bhargava <prarit@redhat.com> Acked-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-08firmware: Introduce request_firmware_direct()Takashi Iwai
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 <prarit@redhat.com> Acked-by: Ming Lei <ming.lei@canonical.com> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-12 21:08:12 +0000