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: Nzhang jun <jun.zhang@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NBart Van Assche <bvanassche@acm.org>
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit [3e358ac2: 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: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NBorislav Petkov <bp@suse.de>
Acked-by: NPrarit Bhargava <prarit@redhat.com>
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NPrarit Bhargava <prarit@redhat.com>
Acked-by: NMing Lei <ming.lei@canonical.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NNeil Horman <nhorman@tuxdriver.com>
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NMaxime Bizon <mbizon@freebox.fr>
Acked-by: NMing Lei <ming.lei@canonical.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use __ATTR_RW() instead of __ATTR() to make it more obvious what the
type of attribute is being created.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes the below compile warning:

drivers/base/firmware_class.c:1254:12: warning: 'cache_firmware' defined
but not used [-Wunused-function]
 static int cache_firmware(const char *fw_name)
            ^
drivers/base/firmware_class.c:1281:12: warning: 'uncache_firmware'
defined but not used [-Wunused-function]
 static int uncache_firmware(const char *fw_name)
            ^
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

fw_priv->buf is accessed in both request_firmware_load() and
writing to sysfs file of 'loading' context, but not protected
by 'fw_lock' entirely. The patch makes sure that access on
'fw_priv->buf' is protected by the lock.

So fixes the double abort problem reported by nirinA raseliarison:

	http://lkml.org/lkml/2013/6/14/188Reported-and-tested-by: NnirinA raseliarison <nirina.raseliarison@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable <stable@vger.kernel.org> # 3.9
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

module reference doesn't cover direct loading path, so this patch
simply holds the module in the whole life time of request_firmware()
to fix the problem.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Looks no driver has the explict requirement for the two exported
API, just don't export them anymore.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit ddf1f064("firmware loader: fix build failure
with !CONFIG_FW_LOADER_USER_HELPER") introduces the below
warning:

drivers/base/firmware_class.c:921:13: warning:
'kill_requests_without_uevent' defined but not used [-Wunused-function]

So fix it by defining kill_requests_without_uevent() only if
CONFIG_PM_SLEEP is set.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes one build failure which is introduced by the patch
below:

	driver core: firmware loader: kill FW_ACTION_NOHOTPLUG requests
	before suspend

When CONFIG_FW_LOADER_USER_HELPER is unset, kill_requests_without_uevent()
should be nop because no userspace loading is involved.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch kills the firmware loading requests of FW_ACTION_NOHOTPLUG
before suspend to avoid blocking suspend because there is no timeout
for these requests.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Generally there are only two drivers which don't need uevent to
handle firmware loading, so don't cache these firmwares during
suspend for these drivers since doing that may block firmware
loading forever.

Both the two drivers are involved in private firmware images, so
they don't hit in direct loading too.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move EXPORT_SYMBOL annotations so they follow immediately after the
closing function brace line.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When a system goes to reboot/shutdown, it tries to disable the
usermode helper via usermodehelper_disable().  This might be blocked
when a driver tries to load a firmware beforehand and it's stuck by
some reason.  For example, dell_rbu driver loads the firmware in
non-hotplug mode and waits for user-space clearing the loading sysfs
flag.  If user-space doesn't clear the flag, it waits forever, thus
blocks the reboot, too.

As a workaround, in this patch, the firmware class driver registers a
reboot notifier so that it can abort all pending f/w bufs before
issuing usermodehelper_disable().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

FW_STATUS_ABORT can be set only during the user-helper invocation,
thus we can ignore the check when CONFIG_HW_LOADER_USER_HELPER is
disabled.
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

By shuffling the code, reduce a few ifdefs in firmware_class.c.
Also, firmware_buf fmt field is changed to is_pages_buf boolean for
simplification.
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds a new kconfig, CONFIG_FW_LOADER_USER_HELPER, and
guards the user-helper codes in firmware_class.c with ifdefs.

Yeah, yeah, there are lots of ifdefs in this patch.  The further
clean-up with code shuffling follows in the next.
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since 3.7 kernel, the firmware loader can read the firmware files
directly, and the traditional user-mode helper is invoked only as a
fallback.  This seems working pretty well, and the next step would be
to reduce the redundant user-mode helper stuff in future.

This patch is a preparation for that: refactor the code for splitting
user-mode helper stuff more easily.  No functional change.
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the requested firmware file size is 0 bytes in the filesytem, we
will try to vmalloc(0), which causes a warning:

  vmalloc: allocation failure: 0 bytes
  kworker/1:1: page allocation failure: order:0, mode:0xd2
    __vmalloc_node_range+0x164/0x208
    __vmalloc_node+0x4c/0x58
    vmalloc+0x38/0x44
    _request_firmware_load+0x220/0x6b0
    request_firmware+0x64/0xc8
    wl18xx_setup+0xb4/0x570 [wl18xx]
    wlcore_nvs_cb+0x64/0x9f8 [wlcore]
    request_firmware_work_func+0x94/0x100
    process_one_work+0x1d0/0x750
    worker_thread+0x184/0x4ac
    kthread+0xb4/0xc0

To fix this, check whether the file size is less than or equal to zero
in fw_read_file_contents().

Cc: stable <stable@vger.kernel.org> [3.7]
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch documents the firmware cache mechanism so that
users of request_firmware() know that it can be called
safely inside device's suspend and resume callback, and
the device's firmware needn't be cached any more by individual
driver itself to deal with firmware loss during system resume.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch introduces one module parameter of 'path' in firmware_class
to support customizing firmware image search path, so that people can
use its own firmware path if the default built-in paths can't meet their
demand[1], and the typical usage is passing the below from kernel command
parameter when 'firmware_class' is built in kernel:

	firmware_class.path=$CUSTOMIZED_PATH

[1], https://lkml.org/lkml/2012/10/11/337

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The comment above fw_file_size() suggests it is noinline for stack size
reasons. Use noinline_for_stack to make this more clear.
Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.net>
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is one race that both request_firmware() with the same
firmware name.

The race scenerio is as below:
CPU1                                                  CPU2
request_firmware() -->
_request_firmware_load() return err                   another request_firmware() is coming -->
_request_firmware_cleanup is called -->               _request_firmware_prepare -->
release_firmware --->                                 fw_lookup_and_allocate_buf -->
                                                      spin_lock(&fwc->lock)
...                                                   __fw_lookup_buf() return true
fw_free_buf() will be called -->                      ...
kref_put -->
decrease the refcount to 0
                                                      kref_get(&tmp->ref) ==> it will trigger warning
                                                                              due to refcount == 0
__fw_free_buf() -->
...                                                   spin_unlock(&fwc->lock)
spin_lock(&fwc->lock)
list_del(&buf->list)
spin_unlock(&fwc->lock)
kfree(buf)
                                                      After that, the freed buf will be used.

The key race is decreasing refcount to 0 and list_del is not protected together by
fwc->lock, and it is possible another thread try to get it between refcount==0
and list_del.

Fix it here to protect it together.
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: Nliu chuansheng <chuansheng.liu@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a race as below when calling request_firmware():
CPU1                                   CPU2
write 0 > loading
mutex_lock(&fw_lock)
...
set_bit FW_STATUS_DONE                 class_timeout is coming
                                       set_bit FW_STATUS_ABORT
complete_all &completion
...
mutex_unlock(&fw_lock)

In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set,
and request_firmware() will return failure due to condition in
_request_firmware_load():
	if (!buf->size || test_bit(FW_STATUS_ABORT, &buf->status))
		retval = -ENOENT;

But from the above scenerio, it should be a successful requesting.
So we need judge if the bit FW_STATUS_DONE is already set before
calling fw_load_abort() in timeout function.

As Ming's proposal, we need change the timer into sched_work to
benefit from using &fw_lock mutex also.
Signed-off-by: Nliu chuansheng <chuansheng.liu@intel.com>
Acked-by: NMing Lei <ming.lei@canonical.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The comment above fw_file_size() suggests it is noinline for stack size
reasons. Use noinline_for_stack to make this more clear.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.net>
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

async.c has provided synchronization mechanism on async_schedule_*,
so use async_synchronize_full_domain to sync caching firmware instead
of reinventing the wheel.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Firstly 'firmware_buf' is introduced to make all loading requests
to share one firmware kernel buffer, so firmware_buf should
be used in direct loading for saving memory and speedup firmware
loading.

Secondly, the commit below

	abb139e7(firmware:teach
	the kernel to load firmware files directly from the filesystem)

introduces direct loading for fixing udev regression, but it
bypasses the firmware cache meachnism, so this patch enables
caching firmware for direct loading case since it is still needed
to solve drivers' dependency during system resume.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Several loading requests may be pending on one same
firmware buf, and this patch moves fw_map_pages_buf()
before complete_all(&fw_buf->completion) and let all
requests see the mapped 'buf->data' once the loading
is completed.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Under 'Opportunistic sleep' situation, system sleep might be
triggered very frequently, so the uncahce work may not be completed
before caching firmware during next suspend.

This patch cancels the uncache work before caching firmware to
fix the problem above.

Also this patch optimizes the cacheing firmware mechanism a bit by
only storing one firmware cache entry for one firmware image.

So if the firmware is still cached during suspend, it doesn't need
to be loaded from user space any more.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fengguang correctly points out that the firmware reading should not use
vfs_read(), since the buffer is in kernel space.

The vfs_read() just happened to work for kernel threads, but sparse
warns about the incorrect address spaces, and it's definitely incorrect
and could fail for other users of the firmware loading.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is a first step in allowing people to by-pass udev for loading
device firmware.  Current versions of udev will deadlock (causing us to
block for the 30 second timeout) under some circumstances if the
firmware is loaded as part of the module initialization path, and this
is causing problems for media drivers in particular.

The current patch hardcodes the firmware path that udev uses by default,
and will fall back to the legacy udev mode if the firmware cannot be
found there.  We'd like to add support for both configuring the paths
and the fallback behaviour, but in the meantime this hopefully fixes the
immediate problem, while also giving us a way forward.

[ v2: Some VFS layer interface cleanups suggested by Al Viro ]
[ v3: use the default udev paths suggested by Kay Sievers ]
Suggested-by: NIvan Kalvachev <ikalvachev@gmail.com>
Acked-by: NGreg KH <gregkh@linuxfoundation.org>
Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Kay Sievers <kay@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch replaces the previous macro of CONFIG_PM with
CONFIG_PM_SLEEP becasue firmware cache is only used in
system sleep situations.

Also this patch fixes the below compile warning when
CONFIG_PM=n:

	drivers/base/firmware_class.c:1147: warning: 'device_cache_fw_images'
	defined but not used
	drivers/base/firmware_class.c:1212: warning:
	'device_uncache_fw_images_delay' defined but not used
Reported-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After starting caching firmware, there is still some time left
before devices are suspended, during the period, request_firmware
or its nowait version may still be triggered by the below situations
to load firmware images which can't be cached during suspend/resume
cycle.

	- new devices added
	- driver bind
	- or device open kind of things

This patch utilizes the piggyback trick to cache firmware for
this kind of situation: just increase the firmware buf's reference
count and add the fw name entry into cache entry list after starting
caching firmware and before syscore_suspend() is called.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>