ARCH=um kernels seems to be stricter about this than ARCH=arm64 kernels,
export cache_firmware & uncache_firmware routines only when
CONFIG_CACHE_FW is enabled.
Bug: 38289596
Change-Id: Ib3bd9b0ede9b6f1a08b5e0e51d117cc43153795f
Signed-off-by: Ajay Dudani <adudani@google.com>
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: 38289596
Change-Id: I1c62227129590f564b127de6dbcaf0001b2c22ad
Signed-off-by: Ajay Dudani <adudani@google.com>
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>
This patch fix spelling typo in Documentation/DocBook.
It is because .html and .xml files are generated by make htmldocs,
I have to fix a typo within the source files.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
commit 2ef7c01c0cdb170142058c6d8fe0697aee4e4d7d upstream.
When wakelock support was added, the wakeup_source_add() function
was updated to set the last_time value of the wakeup source. This
has the unintended side effect of producing confusing output from
pm_print_active_wakeup_sources() when a wakeup source is added
prior to a sleep that is blocked by a different wakeup source.
The function pm_print_active_wakeup_sources() will search for the
most recently active wakeup source when no active source is found.
If a wakeup source is added after a different wakeup source blocks
the system from going to sleep it may have a later last_time value
than the blocking source and be output as the last active wakeup
source even if it has never actually been active.
It looks to me like the change to wakeup_source_add() was made to
prevent the wakelock garbage collection from accidentally dropping
a wakelock during the narrow window between adding the wakelock to
the wakelock list in wakelock_lookup_add() and the activation of
the wakeup source in pm_wake_lock().
This commit changes the behavior so that only the last_time of the
wakeup source used by a wakelock is initialized prior to adding it
to the wakeup source list. This preserves the meaning of the
last_time value as the last time the wakeup source was active and
allows a wakeup source that has never been active to have a
last_time value of 0.
Fixes: b86ff9820f (PM / Sleep: Add user space interface for manipulating wakeup sources, v3)
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 9ae27a8d1f3ebff09191fb8cb1341414547293b2 upstream.
A bulk read can be implemented either through regmap_raw_read, or
by reading each register individually using regmap_read. Both
regmap_read and regmap_bulk_read should return values in native
endian. In the individual case the current implementation calls
format_val to put the data into the output array, which can cause
endian issues. The regmap_read will have already converted the data
into native endian, if the hosts endian differs from the device then
format_val will switch the endian back again.
Rather than using format_val simply use the code that is called if
there is no format_val function. This code supports all cases except
24-bit but there don't appear to be any users of regmap_bulk_read for
24-bit. Additionally, it would have to be a big endian host for the
old code to actually function correctly anyway.
Fixes: 15b8d2c41fe5 ("regmap: Fix regmap_bulk_read in BE mode")
Reported-by: David Rhodes <david.rhodes@cirrus.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
[bwh: Backported to 3.16:
- 64-bit I/O is not supported
- Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit d5b98eb12420ce856caaf57dc5256eedc56a3747 upstream.
When doing a bulk read from a device which lacks raw I/O support we fall
back to doing register at a time reads but we still use the raw
formatters in order to render the data into the word size used by the
device (since bulk reads still operate on the device word size rather
than unsigned ints). This means that devices without raw formatting
such as those that provide reg_read() are not supported. Provide
handling for them by copying the values read into native endian values
of the appropriate size.
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit b8f9a03b741ddfdde4aa8b607fa7d88eb63a6338 upstream.
The current implementation is broken for regmaps that have a reg_stride,
since it doesn't take the stride into account. Correct this by using the
helper function to calculate the register offset.
Fixes: f01ee60fff ("regmap: implement register striding")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
[bwh: Backported to 3.16: Use simple multiplication instead of
regmap_get_offset()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This aligns every column of elements in wakeup_sources to
conveniently check any specific column for suspicious power
consumption wakeup source or for other easily human readable purpose.
Change-Id: I69137fc4af272f392f3e0c1a4bd48d5a5dee7d2c
Signed-off-by: yangdongdong <yangdongdong@xiaomi.com>
commit c6e83cac3eda5f7dd32ee1453df2f7abb5c6cd46 upstream.
pm_genpd_remove_subdomain() iterates over domain's master_links list and
removes matching element thus it has to use safe version of list
iteration.
Fixes: f721889ff6 ("PM / Domains: Support for generic I/O PM domains (v8)")
Cc: 3.1+ <stable@vger.kernel.org> # 3.1+
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
commit 5f0163a5ee9cc7c59751768bdfd94a73186debba upstream.
The put_device() function tests whether its argument is NULL and then
returns immediately. 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>
[wt: backported only to ease next patch as suggested by Jiri]
Change-Id: I06382c480dac9a93c36d3dd30c62a546a8057f73
Signed-off-by: Willy Tarreau <w@1wt.eu>
commit 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 upstream.
Modules which register drivers via standard path (driver_register) in
parallel can cause a warning:
WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
sysfs: cannot create duplicate filename '/module/saa7146/drivers'
Modules linked in: hexium_gemini(+) mxb(+) ...
...
Call Trace:
...
[<ffffffff812e63a2>] sysfs_warn_dup+0x62/0x80
[<ffffffff812e6487>] sysfs_create_dir_ns+0x77/0x90
[<ffffffff8140f2c4>] kobject_add_internal+0xb4/0x340
[<ffffffff8140f5b8>] kobject_add+0x68/0xb0
[<ffffffff8140f631>] kobject_create_and_add+0x31/0x70
[<ffffffff8157a703>] module_add_driver+0xc3/0xd0
[<ffffffff8155e5d4>] bus_add_driver+0x154/0x280
[<ffffffff815604c0>] driver_register+0x60/0xe0
[<ffffffff8145bed0>] __pci_register_driver+0x60/0x70
[<ffffffffa0273e14>] saa7146_register_extension+0x64/0x90 [saa7146]
[<ffffffffa0033011>] hexium_init_module+0x11/0x1000 [hexium_gemini]
...
As can be (mostly) seen, driver_register causes this call sequence:
-> bus_add_driver
-> module_add_driver
-> module_create_drivers_dir
The last one creates "drivers" directory in /sys/module/<...>. When
this is done in parallel, the directory is attempted to be created
twice at the same time.
This can be easily reproduced by loading mxb and hexium_gemini in
parallel:
while :; do
modprobe mxb &
modprobe hexium_gemini
wait
rmmod mxb hexium_gemini saa7146_vv saa7146
done
saa7146 calls pci_register_driver for both mxb and hexium_gemini,
which means /sys/module/saa7146/drivers is to be created for both of
them.
Fix this by a new mutex in module_create_drivers_dir which makes the
test-and-create "drivers" dir atomic.
I inverted the condition and removed 'return' to avoid multiple
unlocks or a goto.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Fixes: fe480a2675 (Modules: only add drivers/ direcory if needed)
Cc: v2.6.21+ <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
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: Ajay Dudani <adudani@google.com>
Commit a938da06 introduced a useful little log message to tell
users/debuggers which wakeup source aborted a suspend. However,
this message is only printed if the abort happens during the
in-kernel suspend path (after writing /sys/power/state).
The full specification of the /sys/power/wakeup_count facility
allows user-space power managers to double-check if wakeups have
already happened before it actually tries to suspend (e.g. while it
was running user-space pre-suspend hooks), by writing the last known
wakeup_count value to /sys/power/wakeup_count. This patch changes
the sysfs handler for that node to also print said log message if
that write fails, so that we can figure out the offending wakeup
source for both kinds of suspend aborts.
Change-Id: I87c38199803f1cc9fce9187062d28fad68ba6052
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This was found during userspace fuzzing test when a large size dma cma
allocation is made by driver(like ion) through userspace.
show_stack+0x10/0x1c
dump_stack+0x74/0xc8
kasan_report_error+0x2b0/0x408
kasan_report+0x34/0x40
__asan_storeN+0x15c/0x168
memset+0x20/0x44
__dma_alloc_coherent+0x114/0x18c
Change-Id: Ia0c4def2ec27ec56e9faf43ed1b8012381e3b253
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: 67a2e213e7e937c41c52ab5bc46bf3f4de469f6e
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[shashim@codeaurora.org: replace %p by %pK in print format]
Signed-off-by: Shiraz Hashim <shashim@codeaurora.org>
Using memset generates unaligned access exception for
device type memory on armv8, use memset_io for
ioremap region.
Change-Id: I26c82d4bed20f1c163953680aa200c95842d3f21
Signed-off-by: Shiraz Hashim <shashim@codeaurora.org>
The global mutex of 'gdp_mutex' is used to serialize creating/querying
glue dir and its cleanup. Turns out it isn't a perfect way because
part(kobj_kset_leave()) of the actual cleanup action() is done inside
the release handler of the glue dir kobject. That means gdp_mutex has
to be held before releasing the last reference count of the glue dir
kobject.
This patch moves glue dir's cleanup after kobject_del() in device_del()
for avoiding the race.
Change-Id: I92b10e62be8129ead5859a285bf964ab0a3ae2fd
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Yijing Wang <wangyijing@huawei.com>
Reported-by: Chandra Sekhar Lingutla <clingutla@codeaurora.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Patch-mainline: linux-arm-kernel @ 2016/4/26 22:57:28
https://lkml.org/lkml/2016/4/26/647
Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
Check if the len is not greater than maximum to prevent buffer overflow.
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Change-Id: I575b0a72bb5448b68353408d71fa8b83420c9088
commit 176fc2d5770a0990eebff903ba680d2edd32e718 upstream.
The in kernel snprintf() will conveniently return the actual length of
the printed string even if not given an output beffer at all so just do
that rather than relying on the user to pass in a suitable buffer,
ensuring that we don't need to worry if the buffer was truncated due to
the size of the buffer passed in.
Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b763ec17ac762470eec5be8ebcc43e4f8b2c2b82 upstream.
If a read is attempted which is smaller than the line length then we may
underflow the subtraction we're doing with the unsigned size_t type so
move some of the calculation to be additions on the right hand side
instead in order to avoid this.
Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
regcache sync can call multi register write to sync multiple
register writes to hardware in one transaction. Change enables
support from soundwire framework to sync multiple registers
in one transaction.
Change-Id: Iafe35bf9b8987fb7214efff0d7d4ae3e0a6a4072
Signed-off-by: Sudheer Papothi <spapothi@codeaurora.org>
Call regmap_raw_multi_reg_write API from regcache sync to sync
multiple registers to the hardware if bus interface supports
multi register write. This change will help in reducing the
latency for syncing the registers to the hardware.
Change-Id: I94d19434dc7465434f10db9f7bd62fcc8246d845
Signed-off-by: Sudheer Papothi <spapothi@codeaurora.org>
Regcache sync can call multi reg write to sync to hardware
using regmap_raw_multi_reg_write API. Provide access to
regmap_raw_multi_reg_write API to call from regcache sync.
Change-Id: I2240cd090e7485efb6dd82fd2dd8f8b1fc8a0d85
Signed-off-by: Sudheer Papothi <spapothi@codeaurora.org>
There is a new capability 'can_multi_write' that device
drivers must set in order to use this multi reg write mode.
This replaces the first definition, which just defined the API.
Change-Id: I578b88aceef495add0f527eec4e8c8b7c4a922cc
Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: Santosh Mardi <gsantosh@codeaurora.org>
Devices with more complex boot proceedures may occasionally apply the
register patch manual. regmap_multi_reg_write is a logical way to do so,
however the patch must be applied with cache bypass on, such that it
doesn't override any user settings. This patch adds a
regmap_multi_reg_write_bypassed function that applies a set of
writes with the bypass enabled.
Change-Id: I68755cd317b100f8c03dfdecace3e7b15068e066
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Santosh Mardi <gsantosh@codeaurora.org>
There should be no need for the writes supplied
to this function to be edited by it so mark them
as const.
Change-Id: I4632540e2d3e8dc684dc19b8f3be7ea7224b5f9d
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Santosh Mardi <gsantosh@codeaurora.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.
Change-Id: Ie523dd835fbeece28e179764059a34d7a92afb65
Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: David Dajun Chen <david.chen@diasemi.com>
Signed-off-by: Santosh Mardi <gsantosh@codeaurora.org>
In soundwire read/write commands, register value is defined
as 8 bit but it is accessed through 32 bit pointer which
may cause out of boundary memory access. Fix this issue by
typecast appropriately.
BUG: KASan: out of bounds access in swrm_read+0x1dc/0x30c at
addr ffffffc089871880
Write of size 4 by task kworker/u8:5/236
==addr ffffffc089871880
[<ffffffc00081d174>] swrm_read+0x1d8/0x30c
[<ffffffc000819808>] swr_read+0x5c/0x74
[<ffffffc000741e58>] regmap_swr_read+0xd8/0x11c
[<ffffffc00073a350>] _regmap_raw_read+0x210/0x314
[<ffffffc00073a4b0>] _regmap_bus_read+0x5c/0xb4
[<ffffffc000739548>] _regmap_read+0xe0/0x1ec
[<ffffffc0007396b8>] regmap_read+0x64/0xa8
[<ffffffc000dc9dd4>] snd_soc_component_read+0x34/0x70
[<ffffffc000dc9f44>] snd_soc_read+0x6c/0x94
Memory state around the buggy address:
ffffffc089871780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffffc089871800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Change-Id: I3c56dffb4ca197e8fc23d54a44282a60254dd001
Signed-off-by: Vidyakumar Athota <vathota@codeaurora.org>
commit 7f5dcaf1fdf289767a126a0a5cc3ef39b5254b06 upstream.
The unregister path of platform_device is broken. On registration, it
will register all resources with either a parent already set, or
type==IORESOURCE_{IO,MEM}. However, on unregister it will release
everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There
are also cases where resources don't get registered in the first place,
like with devices created by of_platform_populate()*.
Fix the unregister path to be symmetrical with the register path by
checking the parent pointer instead of the type field to decide which
resources to unregister. This is safe because the upshot of the
registration path algorithm is that registered resources have a parent
pointer, and non-registered resources do not.
* It can be argued that of_platform_populate() should be registering
it's resources, and they argument has some merit. However, there are
quite a few platforms that end up broken if we try to do that due to
overlapping resources in the device tree. Until that is fixed, we need
to solve the immediate problem.
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Tested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 64526370d11ce8868ca495723d595b61e8697fbf upstream.
Currently, devres_get() passes devres_free() the pointer to devres,
but devres_free() should be given with the pointer to resource data.
Fixes: 9ac7849e35 ("devres: device resource management")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A rogue wakeup source not registered in wakeup_sources list is not visible
from wakeup_sources_stats_show. Check if the wakeup source is registered
properly by looking at the timer struct.
Signed-off-by: jinqian <jinqian@google.com>
Change-Id: Id4b2fdb3cf7fecb2fe7576b2305cd337974665c9
Git-commit: 99a26ce784f9a4a9db1785a071fc9f5036353d5a
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Kaushal Kumar <kaushalk@codeaurora.org>
commit 6f957724b94cb19f5c1c97efd01dd4df8ced323c upstream.
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>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 15b8d2c41fe5839582029f65c5f7004db451cc2b upstream.
In big endian mode regmap_bulk_read gives incorrect data
for byte reads.
This is because memcpy of a single byte from an address
after full word read gives different results when
endianness differs. ie. we get little-end in LE and big-end in BE.
Signed-off-by: Arun Chandran <achandran@mvista.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dev_get_regmap can return NULL and hence map can be NULL.
So check if map is a valid pointer before accessing.
Change-Id: Ied358e0fed551bf0b96e6cd2e0b44ebde990621f
Signed-off-by: Yeleswarapu Nagaradhesh <nagaradh@codeaurora.org>
Use rcu to free objects in wakeup_source_unregister(). These objects must
be allocated through wakeup_source_register().
Replacing synchronize_rcu() with call_rcu() allows multiple calls to
wakeup_source_unregister() to be combined into a single grace period.
CRs-Fixed: 845110
Change-Id: Ib4002db042cf63abb28e6b3df6e3c70c97043bd9
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
PMD_SIZE alignment is required to support
"linux,fixup-reserve-region", fix the same.
Change-Id: I67302a5dfd7738df93a63931b58b87686edb9a75
Signed-off-by: Shiraz Hashim <shashim@codeaurora.org>
For some use cases, it is not known beforehand, how much cma
area size must be reserved. Or the reserved region might
need to be adjusted to support varying use cases. In such
cases maintaining different cma region size in device tree
is difficult.
Introduce an optional cma property,
"linux,fixup-reserve-region" which works in tandem with
"linux,reserve-region" that tries to shrink the cma area on
first successful allocation. After which it returns the
additional pages from the reserved region back to the
system.
fixup region requires base and size to be aligned to
SECTION_SIZE. If it isn't so, then such regions simply
fall back to carve-out region.
Change-Id: I1f71baf146b978398946f466bbba2f192560593b
Signed-off-by: Shiraz Hashim <shashim@codeaurora.org>
Add null check for the return value of kmem_cache_alloc before
using it.
CRs-Fixed: 836643
Change-Id: If0d8055b84fb9f9c372a68acc2a53f39035fffef
Signed-off-by: Devesh Jhunjhunwala <deveshj@codeaurora.org>
There is a possibility that a wakeup source event is received after
the device prepares to suspend which might cause the suspend to abort.
This patch adds the functionality of reporting the last active wakeup
source which is currently not active but caused the suspend to abort reason
via the /sys/kernel/power/last_wakeup_reason file.
Change-Id: I778ab471cb075d4b3859c798f6e3ff72faf7edc0
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Git-commit: c8b4bc552cef9e24427b12fee8763d1702f8d57a
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Vignesh Radhakrishnan <vigneshr@codeaurora.org>
Add soundwire bus support to regmap. This change enables
codec drivers using the soundwire hardware interface to use
regmap interface for register read/write functionality.
Change-Id: I503ba80401cd2f45fafc95e6c9da4e5b05c39ec4
Signed-off-by: Sudheer Papothi <spapothi@codeaurora.org>
Ajay Dudani
syphyr
Shaibal Dutta
Masanari Iida
Doug Berger
Charles Keepax
Mark Brown
yangdongdong
Krzysztof Kozlowski
Markus Elfring
Jiri Slaby
Tim Murray
Julius Werner
Luca Stefani
LuK1337
Luca Stefani
Rohit Vaswani
Shiraz Hashim
Pradosh Das
Ming Lei
Ruchi Kandoi
Tuomas Tynkkynen
Sudheer Papothi
Linux Build Service Account
Santosh Mardi
Vidyakumar Athota
Grant Likely
Masahiro Yamada
Theodore Ts'o
jinqian
Linus Torvalds
Arun Chandran
Yeleswarapu Nagaradhesh
Patrick Daly
Devesh Jhunjhunwala