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 bus_unregister() triggers a use-after-free with
CONFIG_DEBUG_KOBJECT_RELEASE=y. This patch avoids that the
following sequence triggers a kernel crash with memory poisoning
enabled:
* bus_register()
* driver_register()
* driver_unregister()
* bus_unregister()

The above sequence causes the bus private data to be freed from
inside the bus_unregister() call although it is not guaranteed in
that function that the reference count on the bus private data has
dropped to zero. As an example, with CONFIG_DEBUG_KOBJECT_RELEASE=y
the ${bus}/drivers kobject is still holding a reference on
bus->p->subsys.kobj via its parent pointer at the time the bus
private data is freed. Fix this by deferring freeing the bus private
data until the last kobject_put() call on bus->p->subsys.kobj.

The kernel oops triggered by the above sequence and with memory
poisoning enabled and that is fixed by this patch is as follows:

general protection fault: 0000 [#1] PREEMPT SMP
CPU: 3 PID: 2711 Comm: kworker/3:32 Tainted: G        W  O 3.13.0-rc4-debug+ #1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: events kobject_delayed_cleanup
task: ffff880037f866d0 ti: ffff88003b638000 task.ti: ffff88003b638000
Call Trace:
 [<ffffffff81263105>] ? kobject_get_path+0x25/0x100
 [<ffffffff81264354>] kobject_uevent_env+0x134/0x600
 [<ffffffff8126482b>] kobject_uevent+0xb/0x10
 [<ffffffff81262fa2>] kobject_delayed_cleanup+0xc2/0x1b0
 [<ffffffff8106c047>] process_one_work+0x217/0x700
 [<ffffffff8106bfdb>] ? process_one_work+0x1ab/0x700
 [<ffffffff8106c64b>] worker_thread+0x11b/0x3a0
 [<ffffffff8106c530>] ? process_one_work+0x700/0x700
 [<ffffffff81074b70>] kthread+0xf0/0x110
 [<ffffffff81074a80>] ? insert_kthread_work+0x80/0x80
 [<ffffffff815673bc>] ret_from_fork+0x7c/0xb0
 [<ffffffff81074a80>] ? insert_kthread_work+0x80/0x80
Code: 89 f8 48 89 e5 f6 82 c0 27 63 81 20 74 15 0f 1f 44 00 00 48 83 c0 01 0f b6 10 f6 82 c0 27 63 81 20 75 f0 5d c3 66 0f 1f 44 00 00 <80> 3f 00 55 48 89 e5 74 15 48 89 f8 0f 1f 40 00 48 83 c0 01 80
RIP  [<ffffffff81267ed0>] strlen+0x0/0x30
 RSP <ffff88003b639c70>
---[ end trace 210f883ef80376aa ]---
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>

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 deleted variable is always 1 in current code.
Initialize deleted variable to be 0, so delete_path() will be called only when
necessary.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the addition of dev_attr_online fails, device_add_attrs() should
remove device attribute groups as well as type and class attribute
groups before returning an error code.  Make that happen.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We call put_device() in the error path, which is fine for dev==NULL.
However, in case kobject_set_name_vargs() fails, we have dev!=NULL but
device_initialized() wasn't called, yet.

Fix this by splitting device_register() into explicit calls to
device_add() and an early call to device_initialize().
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.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>

Commit 5a87182a (cpufreq: suspend governors on system
suspend/hibernate) causes hibernation problems to happen on
Bjørn Mork's and Paul Bolle's systems, so revert it.

Fixes: 5a87182a (cpufreq: suspend governors on system suspend/hibernate)
Reported-by: NBjørn Mork <bjorn@mork.no>
Reported-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch adds cpufreq suspend/resume calls to dpm_{suspend|resume}_noirq()
for handling suspend/resume of cpufreq governors.

Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found anr issue where
tunables configuration for clusters/sockets with non-boot CPUs was
getting lost after suspend/resume, as we were notifying governors
with CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that
policy and so deallocating memory for tunables. This is fixed by
this patch as we don't allow any operation on governors after
device suspend and before device resume now.
Reported-and-tested-by: NLan Tianyu <tianyu.lan@intel.com>
Reported-by: NJinhyuk Choi <jinchoi@broadcom.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog, minor cleanups]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

clk_get() returns an error pointer, or a valid token to pass back to the
clock API. Hence, the result must be checked with IS_ERR(), not by
comparison against NULL.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Signed-off-by: NCourtney Cavin <courtney.cavin@sonymobile.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Use this new function to make code more comprehensible, since we are
reinitialzing the completion, not initializing.

[akpm@linux-foundation.org: linux-next resyncs]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13)
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it.  Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead.  For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.

The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles).  However, there are more reasons
why it may be useful.

First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros.  Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part

If a device prepare callback for some reason would fail, the PM core
prevented the device from going inactive forever.

In this case, to reverse the pm_runtime_get_noresume() we invokes the
asyncronous pm_runtime_put(), thus restoring the usage count.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

fix a trivial copy'n'paste error in the regmap kerneldoc, s/write/read/
for the regmap_read(), regmap_raw_read() and regmap_bulk_read() routines
Signed-off-by: NGerhard Sittig <gsi@denx.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

NFSv4 uses leases to guarantee that clients can cache metadata as well
as data.

Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: David Howells <dhowells@redhat.com>
Cc: Tyler Hicks <tyhicks@canonical.com>
Cc: Dustin Kirkland <dustin.kirkland@gazzang.com>
Acked-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

We need to break delegations on any operation that changes the set of
links pointing to an inode.  Start with unlink.

Such operations also hold the i_mutex on a parent directory.  Breaking a
delegation may require waiting for a timeout (by default 90 seconds) in
the case of a unresponsive NFS client.  To avoid blocking all directory
operations, we therefore drop locks before waiting for the delegation.
The logic then looks like:

	acquire locks
	...
	test for delegation; if found:
		take reference on inode
		release locks
		wait for delegation break
		drop reference on inode
		retry

It is possible this could never terminate.  (Even if we take precautions
to prevent another delegation being acquired on the same inode, we could
get a different inode on each retry.)  But this seems very unlikely.

The initial test for a delegation happens after the lock on the target
inode is acquired, but the directory inode may have been acquired
further up the call stack.  We therefore add a "struct inode **"
argument to any intervening functions, which we use to pass the inode
back up to the caller in the case it needs a delegation synchronously
broken.

Cc: David Howells <dhowells@redhat.com>
Cc: Tyler Hicks <tyhicks@canonical.com>
Cc: Dustin Kirkland <dustin.kirkland@gazzang.com>
Acked-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Commit fa180eb4 (PM / Runtime: Idle devices asynchronously after
probe|release) modified __device_release_driver() to call
pm_runtime_put(dev) instead of pm_runtime_put_sync(dev) before
detaching the driver from the device.  However, that was a mistake,
because pm_runtime_put(dev) causes rpm_idle() to be queued up and
the driver may be gone already when that function is executed.
That breaks the assumptions the drivers have the right to make
about the core's behavior on the basis of the existing documentation
and actually causes problems to happen, so revert that part of
commit fa180eb4 and restore the previous behavior of
__device_release_driver().
Reported-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Fixes: fa180eb4 (PM / Runtime: Idle devices asynchronously after probe|release)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+

Add basic support for the System Power Management Interface (SPMI) bus.
This is a simple implementation which only implements register accesses
via the Extended Register Read/Write Long commands.
Signed-off-by: NJosh Cartwright <joshc@codeaurora.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Since Operating Performance Points (OPP) functions are specific
to device specific power management, be specific and rename opp.h
to pm_opp.h
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since Operating Performance Points (OPP) data structures are specific
to device specific power management, be specific and rename opp_* data
structures in OPP library with dev_pm_opp_* equivalent.

Affected structures are:
 struct opp
 enum opp_event

Minor checkpatch warning resulting of this change was fixed as well.
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since Operating Performance Points (OPP) functions are specific to
device specific power management, be specific and rename opp_*
accessors in OPP library with dev_pm_opp_* equivalent.

Affected functions are:
 opp_get_voltage
 opp_get_freq
 opp_get_opp_count
 opp_find_freq_exact
 opp_find_freq_floor
 opp_find_freq_ceil
 opp_add
 opp_enable
 opp_disable
 opp_get_notifier
 opp_init_cpufreq_table
 opp_free_cpufreq_table
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated memory.  However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong assumptions
about memory being zero'd upon allocation.

To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.
Signed-off-by: NKevin Hilman <khilman@linaro.org>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If called early enough, regmap_debugfs_init causes a crash, if the
fs subsystem does not have its mount cache created yet. Even if this
would work, the root node for the regmap debugfs is still missing,
thus postpone the regmap_debugfs_init in this case until the root
node is created. A special regmap_debugfs_early list is created for
this purpose which is parsed later in the boot.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

clear the status bit if the mask register doesn't prevent
the chip level irq from being asserted

OR in the following sequence, there will be irq storm happens:
1) interrupt is triggered;
2) another thread disables it(the mask bit is set);
3) _Then_ the interrupt thread is not ACKed(the status bit is not cleared),
   and it's ignored;
4) if the irq is still asserted because of the uncleared status bit,
   the irq storm happens;
Signed-off-by: NYi Zhang <yizhang@marvell.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Rather than hard-lock the kernel, dump the suspend/resume thread stack
and panic() to capture a message in pstore when a driver takes too long
to suspend/resume. Default suspend/resume watchdog timeout is set to 12
seconds to be longer than the usbhid 10 second timeout, but could be
changed at compile time.

Exclude from the watchdog the time spent waiting for children that
are resumed asynchronously and time every device, whether or not they
resumed synchronously.

This patch is targeted for mobile devices where a suspend/resume lockup
could cause a system reboot. Information about failing device can be
retrieved in subsequent boot session by mounting pstore and inspecting
the log. Laptops with EFI-enabled pstore could also benefit from
this feature.

The hardware watchdog timer is likely suspended during this time and
couldn't be relied upon. The soft-lockup detector would eventually tell
that tasks are not scheduled, but would provide little context as to why.
The patch hence uses system timer and assumes it is still active while the
devices are suspended/resumed.

This feature can be enabled/disabled during kernel configuration.

This change is based on earlier work by San Mehat.
Signed-off-by: NBenoit Goby <benoit@android.com>
Signed-off-by: NZoran Markovic <zoran.markovic@linaro.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When inserting a wrong value to /sys/devices/system/memory/memoryX/state file,
following messages are shown. And device_hotplug_lock is never released.

================================================
[ BUG: lock held when returning to user space! ]
3.12.0-rc4-debug+ #3 Tainted: G        W
------------------------------------------------
bash/6442 is leaving the kernel with locks still held!
1 lock held by bash/6442:
 #0:  (device_hotplug_lock){+.+.+.}, at: [<ffffffff8146cbb5>] lock_device_hotplug_sysfs+0x15/0x50

This issue was introdued by commit fa2be40f (drivers: base: use standard
device online/offline for state change).

This patch releases device_hotplug_lcok when store_mem_state returns EINVAL.
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: NToshi Kani <toshi.kani@hp.com>
CC: Seth Jennings <sjenning@linux.vnet.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Replace pr_debug() with dev_dbg().
Signed-off-by: Nethan.zhao <ethan.kernel@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, devm_ managed memory only supports kzalloc.

Convert the devm_kzalloc implementation to devm_kmalloc and remove the
complete memset to 0 but still set the initial struct devres header and
whatever padding before data to 0.

Add the other normal alloc variants as static inlines with __GFP_ZERO
added to the gfp flag where appropriate:

	devm_kzalloc
	devm_kcalloc
	devm_kmalloc_array

Add gfp.h to device.h for the newly added static inlines.

akpm: the current API forces us to replace kmalloc() with kzalloc() when
performing devm_ conversions.  This adds a relatively minor overhead.
More significantly, it will defeat kmemcheck used-uninitialized checking,
and for a particular driver, losing used-uninitialised checking for their
core controlling data structures will significantly degrade kmemcheck
usefulness.
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Sangjung Woo <sangjung.woo@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For devices which don't have a .runtime_idle() callback or if it
returns 0, rpm_idle() will end up in triggering a call to
rpm_suspend(), thus trying to carry out a runtime suspend directly
from runtime_idle().

In the above situation we want to respect devices which has enabled
autosuspend, we therfore append the flag sent to rpm_suspend with
RPM_AUTO.

Do note that drivers still needs to update the device last busy mark,
to control the delay for this circumstance.

Updated runtime PM documentation accordingly.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NKevin Hilman <khilman@linaro.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Extend the interface for async I/O by allowing the value buffer to be
omitted and sending the value as part of the register buffer, minimising
the number of separate hardware operations required.
Signed-off-by: NMark Brown <broonie@linaro.org>

If the value is zero then assume it has been included in the register data
and don't send anything, minimising the number of interactions with the
hardware.
Signed-off-by: NMark Brown <broonie@linaro.org>

New API regmap_multi_reg_write() is defined that allows a set of reg,val
pairs to be written to a I2C client device as one block transfer from the
point of view of a single I2C master system.

A simple demonstration implementation is included that just splits the
block write request into a sequence of single register writes.

The implementation will be modified later to support those I2C clients
that implement the alternative non-standard MULTIWRITE block write mode
so to achieve a single I2C transfer that will be atomic even in multiple
I2C master systems.
Signed-off-by: NAnthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: NDavid Dajun Chen <david.chen@diasemi.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Try to speed up I/O a little by not synchronising until we are finished
scheduling writes. A brief survey of existing users suggests we have none
that would currently benefit from an async cache sync.
Signed-off-by: NMark Brown <broonie@linaro.org>

Try to speed up patch application a little using async I/O.
Signed-off-by: NMark Brown <broonie@linaro.org>

When regmap_bulk_write() is called with the map->use_single_rw flag set
an immediate mutex deadlock happens because regmap_raw_write() is called
after obtaining the mutex and regmap_raw_write() itself then tries to
obtain the mutex as well.

It is obvious that no one other than myself tried it with a real device.
I did, but only for the purposes of an experiment and demonstration.

But even if this situation will never ever happen with a real device, it
is a bug and therefore should be fixed.
Signed-off-by: NAnthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Make it easier for drivers to include single register writes in
asynchronous sequences by providing async versions of the write
and update bits operations. The update bits operations are only
likely to be effective when used with devices that have caches
but this is common enough to be useful.
Signed-off-by: NMark Brown <broonie@linaro.org>