When booting with EFI, we acquire the EFI memory map after parsing the
early params. This unfortuantely renders the option useless as we call
memblock_enforce_memory_limit (which uses memblock_remove_range behind
the scenes) before we've added any memblocks. We end up removing
nothing, then adding all of memory later when efi_init calls
reserve_regions.
Instead, we can log the limit and apply this later when we do the rest
of the memblock work in memblock_init, which should work regardless of
the presence of EFI. At the same time we may as well move the early
parameter into arm64's mm/init.c, close to arm64_memblock_init.
Any memory which must be mapped (e.g. for use by EFI runtime services)
must be mapped explicitly reather than relying on the linear mapping,
which may be truncated as a result of a mem= option passed on the kernel
command line.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit 6083fe74b7)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
Initialise in6 to avoid...
In file included from include/net/inetpeer.h:15:0,
from include/net/route.h:28,
from include/net/inet_hashtables.h:32,
from include/net/tcp.h:37,
from net/ipv4/tcp.c:275:
net/ipv4/tcp.c: In function ‘tcp_nuke_addr’:
include/net/ipv6.h:417:34: warning: ‘in6’ may be used uninitialized in this function [-Wmaybe-uninitialized]
return ((ul1[0] ^ ul2[0]) | (ul1[1] ^ ul2[1])) == 0UL;
^
net/ipv4/tcp.c:3513:19: note: ‘in6’ was declared here
struct in6_addr *in6;
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Commit 57114e95e8 ("cgroup: refactor allow_attach function into common
code") unnecessarily added a dummy definition for
subsys_cgroup_allow_attach when CONFIG_CGROUP is not set, so remove it
to prevent warnings like...
include/linux/cgroup.h:907:18: warning: 'struct cgroup_taskset' declared inside parameter list
struct cgroup_taskset *tset)
^
include/linux/cgroup.h:907:18: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/cgroup.h:907:18: warning: 'struct cgroup' declared inside parameter list
CC kernel/events/core.o
In file included from kernel/events/core.c:41:0:
include/linux/cgroup.h:907:18: warning: 'struct cgroup_taskset' declared inside parameter list
struct cgroup_taskset *tset)
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Create uids from kuids using from_kuid_munged(),
otherwise we run into following build error and warnings:
--------------------
CC drivers/misc/uid_cputime.o
drivers/misc/uid_cputime.c: In function ‘uid_stat_show’:
drivers/misc/uid_cputime.c:90:36: error: incompatible type for argument 1 of ‘find_or_register_uid’
drivers/misc/uid_cputime.c:54:26: note: expected ‘uid_t’ but argument is of type ‘kuid_t’
drivers/misc/uid_cputime.c:94:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘kuid_t’ [-Wformat]
drivers/misc/uid_cputime.c: In function ‘process_notifier’:
drivers/misc/uid_cputime.c:194:6: error: incompatible types when assigning to type ‘uid_t’ from type ‘kuid_t’
make[2]: *** [drivers/misc/uid_cputime.o] Error 1
--------------------
Change-Id: Ifecb98001f7fe2fac74d1ef3e1abd03d43fc9059
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
(cherry picked from commit b0f4decae627cf2d74e6f72c7ecb939c77d48625)
To avoid the following warning when running merge_config.sh with
this config fragment...
./.tmp.config.37TtCkZvtp:92:warning: override: reassigning to symbol FUNCTION_TRACER
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Warning:
In file included from scripts/kconfig/zconf.tab.c:2537:0:
scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized]
jump->offset = strlen(r->s);
Simplifies the test logic because (head && local) means (jump != 0)
and makes GCC happy when checking if the jump pointer was initialized.
Signed-off-by: Peter Kümmel <syntheticpp@gmx.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
(cherry picked from commit 2d56030609)
Signed-off-by: Jon Medhurst <tixy@linaro.org>
The struct gstr has a capacity that may differ from the actual string length.
However, a string manipulation in the function search_conf made the assumption
that it is the same, which led to messing up some search results, especially
when the content of the gstr in use had not yet reached at least 63 chars.
Signed-off-by: Martin Walch <walch.martin@web.de>
Acked-by: Wang YanQing <udknight@gmail.com>
Acked-by: Benjamin Poirier <bpoirier@suse.de>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
(cherry picked from commit 503c823048)
Signed-off-by: Jon Medhurst <tixy@linaro.org>
In file included from scripts/sortextable.c:194:0:
scripts/sortextable.c: In function `main':
scripts/sortextable.h:176:3: warning: `relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
memset(relocs, 0, relocs_size);
^
scripts/sortextable.h:106:6: note: `relocs_size' was declared here
int relocs_size;
^
In file included from scripts/sortextable.c:192:0:
scripts/sortextable.h:176:3: warning: `relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
memset(relocs, 0, relocs_size);
^
scripts/sortextable.h:106:6: note: `relocs_size' was declared here
int relocs_size;
^
gcc 4.9.1
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Reviewed-by: Jamie Iles <jamie.iles@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 7cbc0ea79d)
Signed-off-by: Jon Medhurst <tixy@linaro.org>
nfqnl_zcopy can now modify the 'from' sk_buff, so drop the const
qualifier and fix build warnings like:
net/netfilter/nfnetlink_queue_core.c: In function ‘nfqnl_zcopy’:
net/netfilter/nfnetlink_queue_core.c:264:15: warning: passing argument 1 of ‘skb_orphan_frags’ discards ‘const’ qualifier from pointer target type
if (unlikely(skb_orphan_frags(from, GFP_ATOMIC))) {
Fixes: c5f0c0e752 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors")
Signed-off-by: Jon Medhurst <tixy@linaro.org>
This fixes the following warnings when building for arm64...
drivers/gpu/drm/drm_gem_cma_helper.c: In function ‘drm_gem_cma_descr ibe’:
drivers/gpu/drm/drm_gem_cma_helper.c:273:4: warning: format ‘%Zx’ expects argument of type ‘size_t’, but argument 6 has type ‘dma_addr_t’ [-Wformat=]
off, cma_obj->paddr, cma_obj->vaddr, obj->size);
^
drivers/gpu/drm/drm_gem_cma_helper.c:273:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 8 has type ‘size_t’ [-Wformat=]
Signed-off-by: Jon Medhurst <tixy@linaro.org>
In LSK's linux-linaro-lsk-android branch, this merge
bb0dddf615
broke drivers/base/cpu.c
Because this patch appears twice:
197028d 2014-02-08 cpu: add generic support for CPU feature based
module autoloading [Ard Biesheuvel]
126ef42 2014-02-08 cpu: add generic support for CPU feature based
module autoloading [Ard Biesheuvel]
And the merge edited the file to the old contents.
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Commit cd5c2cc93d (hmp: Remove potential for task_struct access
race) introduced a put_task_struct() to prevent races, but in doing so
introduced potential spinlock recursion. (This change was further
consolidated in commit 0baa5811ba -- sched: hmp: unify active
migration code.)
Unfortunately, the put_task_struct() is done while the runqueue
spinlock is held, but put_task_struct() can also cause a reschedule
causing the runqueue lock to be acquired recursively.
To fix, move the put_task_struct() outside the runqueue spinlock.
Reported-by: Victor Lixin <victor.lixin@hisilicon.com>
Cc: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Jon Medhurst <tixy@linaro.org>
Reviewed-by: Alex Shi <alex.shi@linaro.org>
Reviewed-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.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: I1760d462f497b33e425f5565cb6cff5973932ec3
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
commit 8d465bb777 upstream (net-next).
This command is missing.
Change-Id: Id2c9344ca1ab2c96e0b758ad1efb38e16cf23b86
Fixes: 5c79de6e79 ("[XFRM]: User interface for handling XFRM_MSG_MIGRATE")
Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit b0b59b0056 upstream (net-next).
This command is missing.
Change-Id: I8fa3b1b9815296d3b001244d2212f79f5654bd01
Fixes: 97a64b4577 ("[XFRM]: Introduce XFRM_MSG_REPORT.")
Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 5b5800fad0 upstream (net-next).
These commands are missing.
Change-Id: I3fd1d3d700592c653e1a5c5199125805d55aaa95
Fixes: 28d8909bc7 ("[XFRM]: Export SAD info.")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 5e6deebafb upstream (net-next).
This command is missing.
Change-Id: Id0a0d9bf7a4af98a8f761fec902d1296138a911f
Fixes: ecfd6b1837 ("[XFRM]: Export SPD info")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 2b7834d3e1 upstream (net-next).
This new command is missing.
Change-Id: If511000c19aa9af7220ff775d88ace9834b35dcb
Fixes: 880a6fab8f ("xfrm: configure policy hash table thresholds by netlink")
Reported-by: Christophe Gouault <christophe.gouault@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Extend the generic ioctl permission check with support for per-command
filtering. Source/target/class sets including the ioctl permission may
additionally include a set of commands. Example:
allow <source> <target>:<class> { 0x8910-0x8926 0x892A-0x8935 }
auditallow <source> <target>:<class> 0x892A
When ioctl commands are omitted only the permissions are checked. This
feature is intended to provide finer granularity for the ioctl
permission which may be too imprecise in some circumstances. For
example, the same driver may use ioctls to provide important and
benign functionality such as driver version or socket type as well as
dangerous capabilities such as debugging features, read/write/execute
to physical memory or access to sensitive data. Per-command filtering
provides a mechanism to reduce the attack surface of the kernel, and
limit applications to the subset of commands required.
The format of the policy binary has been modified to include ioctl
commands, and the policy version number has been incremented to
POLICYDB_VERSION_IOCTL_OPERATIONS=30 to account for the format change.
Bug: 18087110
Change-Id: Ibf0e36728f6f3f0d5af56ccdeddee40800af689d
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Add information about ioctl calls to the LSM audit data. Log the
file path and command number.
Bug: 18087110
Change-Id: Idbbd106db6226683cb30022d9e8f6f3b8fab7f84
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
commit 87f966d97b upstream.
On a MIPS Malta board, tons of fifo underflow errors have been observed
when using u-boot as bootloader instead of YAMON. The reason for that
is that YAMON used to set the pcnet device to SRAM mode but u-boot does
not. As a result, the default Tx threshold (64 bytes) is now too small to
keep the fifo relatively used and it can result to Tx fifo underflow errors.
As a result of which, it's best to setup the SRAM on supported controllers
so we can always use the NOUFLO bit.
Cc: <netdev@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Cc: Don Fry <pcnet32@frontier.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb344ca5b9 upstream.
Commit 746c9e9f92 "of/base: Fix PowerPC address parsing hack" limited
the applicability of the workaround whereby a missing ranges is treated
as an empty ranges. This workaround was hiding a bug in the etsec2
device tree nodes, which have children with reg, but did not have
ranges.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Reported-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 98cf21c61a upstream.
Fix B-tree corruption when a new record is inserted at position 0 in the
node in hfs_brec_insert(). In this case a hfs_brec_update_parent() is
called to update the parent index node (if exists) and it is passed
hfs_find_data with a search_key containing a newly inserted key instead
of the key to be updated. This results in an inconsistent index node.
The bug reproduces on my machine after an extents overflow record for
the catalog file (CNID=4) is inserted into the extents overflow B-tree.
Because of a low (reserved) value of CNID=4, it has to become the first
record in the first leaf node.
The resulting first leaf node is correct:
----------------------------------------------------
| key0.CNID=4 | key1.CNID=123 | key2.CNID=456, ... |
----------------------------------------------------
But the parent index key0 still contains the previous key CNID=123:
-----------------------
| key0.CNID=123 | ... |
-----------------------
A change in hfs_brec_insert() makes hfs_brec_update_parent() work
correctly by preventing it from getting fd->record=-1 value from
__hfs_brec_find().
Along the way, I removed duplicate code with unification of the if
condition. The resulting code is equivalent to the original code
because node is never 0.
Also hfs_brec_update_parent() will now return an error after getting a
negative fd->record value. However, the return value of
hfs_brec_update_parent() is not checked anywhere in the file and I'm
leaving it unchanged by this patch. brec.c lacks error checking after
some other calls too, but this issue is of less importance than the one
being fixed by this patch.
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Cc: Joe Perches <joe@perches.com>
Reviewed-by: Vyacheslav Dubeyko <slava@dubeyko.com>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Cc: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ab7c7bb6f4 upstream.
__dm_destroy() must take the suspend_lock so that its presuspend and
postsuspend calls do not race with an internal suspend.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 40c8790bcb upstream.
When the driver sets this rate a power of zero value is set causing
data flow stoppage until another rate is tried.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d525211f9d upstream.
Vince reported a watchdog lockup like:
[<ffffffff8115e114>] perf_tp_event+0xc4/0x210
[<ffffffff810b4f8a>] perf_trace_lock+0x12a/0x160
[<ffffffff810b7f10>] lock_release+0x130/0x260
[<ffffffff816c7474>] _raw_spin_unlock_irqrestore+0x24/0x40
[<ffffffff8107bb4d>] do_send_sig_info+0x5d/0x80
[<ffffffff811f69df>] send_sigio_to_task+0x12f/0x1a0
[<ffffffff811f71ce>] send_sigio+0xae/0x100
[<ffffffff811f72b7>] kill_fasync+0x97/0xf0
[<ffffffff8115d0b4>] perf_event_wakeup+0xd4/0xf0
[<ffffffff8115d103>] perf_pending_event+0x33/0x60
[<ffffffff8114e3fc>] irq_work_run_list+0x4c/0x80
[<ffffffff8114e448>] irq_work_run+0x18/0x40
[<ffffffff810196af>] smp_trace_irq_work_interrupt+0x3f/0xc0
[<ffffffff816c99bd>] trace_irq_work_interrupt+0x6d/0x80
Which is caused by an irq_work generating new irq_work and therefore
not allowing forward progress.
This happens because processing the perf irq_work triggers another
perf event (tracepoint stuff) which in turn generates an irq_work ad
infinitum.
Avoid this by raising the recursion counter in the irq_work -- which
effectively disables all software events (including tracepoints) from
actually triggering again.
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/20150219170311.GH21418@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa75ebc275 upstream.
Some APs experience problems when working with
U-APSD. Decreasing the probability of that
happening by using legacy mode for all ACs but VO
isn't enough.
Cisco 4410N originally forced us to enable VO by
default only because it treated non-VO ACs as
legacy.
However some APs (notably Netgear R7000) silently
reclassify packets to different ACs. Since u-APSD
ACs require trigger frames for frame retrieval
clients would never see some frames (e.g. ARP
responses) or would fetch them accidentally after
a long time.
It makes little sense to enable u-APSD queues by
default because it needs userspace applications to
be aware of it to actually take advantage of the
possible additional powersavings. Implicitly
depending on driver autotrigger frame support
doesn't make much sense.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 496fcc294d upstream.
As HT/VHT depend heavily on QoS/WMM, it's not a good idea to
let userspace add clients that have HT/VHT but not QoS/WMM.
Since it does so in certain cases we've observed (client is
using HT IEs but not QoS/WMM) just ignore the HT/VHT info at
this point and don't pass it down to the drivers which might
unconditionally use it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 75c3d0bf9c upstream.
This patch fixes the incorrect use of __transport_register_session()
in tcm_qla2xxx_check_initiator_node_acl() code, that does not perform
explicit se_tpg->session_lock when accessing se_tpg->tpg_sess_list
to add new se_sess nodes.
Given that tcm_qla2xxx_check_initiator_node_acl() is not called with
qla_hw->hardware_lock held for all accesses of ->tpg_sess_list, the
code should be using transport_register_session() instead.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
Cc: Quinn Tran <quinn.tran@qlogic.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d556546e7e upstream.
This patch adds a missing set of conditional check braces in
ft_invl_hw_context() originally introduced by commit dcd998ccd
when handling DDP failures in ft_recv_write_data() code.
commit dcd998ccdb
Author: Kiran Patil <kiran.patil@intel.com>
Date: Wed Aug 3 09:20:01 2011 +0000
tcm_fc: Handle DDP/SW fc_frame_payload_get failures in ft_recv_write_data
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Kiran Patil <kiran.patil@intel.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 07892b1035 upstream.
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2bf4c1d483 upstream.
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 08641d9b7b upstream.
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eaddf6fd95 upstream.
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 24cc883c1f upstream.
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>