PD#138714: osd logo optimize
1.move logo module,merge it into osd driver
2.fix remove get_logo_vmode() api caused video.c compile error
Change-Id: I8c90c0313fbf5661082627f7a37b3e465ba594da
Signed-off-by: Pengcheng Chen <pengcheng.chen@amlogic.com>
PD#141217: add pwm support for m8b
1.add support for m8b
2.add pwm driver support for txlx
verified on m8b
Change-Id: Id6980f090062d05315ca03a7248e4d318181c76c
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
PD#141217: add i2c support on m8b.
add i2c ao~d support.
Change-Id: Ibc46745d99b172186255fc3f47be42e04480c9a9
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
PD#141217: add cpu hotplug support for m8b
1) enable CONFIG_AMLOGIC_CPU_HOTPLUG
2) clusterID of M8b is 2
Change-Id: I8f6dc6ced430364beb5eb82f20cb7034eb714eb0
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
PD#141217: initial add emmc dirver support on m8b
1) add emmc driver support
HS200 mode 85M
2) add sd driver support
HS mode 38M
test on m8b_m200.
Change-Id: I1575c45af2e1246019d54a8092ee29e1da0a1a70
Signed-off-by: Nan Li <nan.li@amlogic.com>
PD#141217: add pinctrl & gpio support for m8b
fix gpio irq bugs
TODO: because of limitation of software framework and gpio irq
lines, the ao gpio pins on M8B don't support external irq detect,
and suggest using ee gpio pins to detect.
Change-Id: I933b71104877d97444107d8fba56e3540f94efff
Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
PD#141217: crypto drivers based on BLKMV are under
CONFIG_AMLOGIC_CRYPTO_BLKMV
and move DMA version to CONFIG_AMLOGIC_CRYPTO_DMA
Change-Id: I42561765a599dc3611a144da6a455df5bded59d5
Signed-off-by: Matthew Shyu <matthew.shyu@amlogic.com>
PD#138714: initial add the driver
1.Add amlogic ionvideo driver;
2.device tree support of ionvideo for p212/q200/skt/p400/p401;
3.related Makefiles/Kconfig/Headfiles update;
Change-Id: I2c0013a8ab256f73618b7f583c3b275fa3aaeebb
Signed-off-by: Guosong Zhou <guosong.zhou@amlogic.com>
PD#138714: dts: add led, watchdog, and jtag device node
Change-Id: Ie367c0e7acd67be9d12d5d3b32ac43d8a4eee10f
Signed-off-by: Bo Yang <bo.yang@amlogic.com>
PD#138714: when emmc suspend & resume, emmc probe fail.
Change-Id: Ib62092ecc96a3692f02a2509757177713af7de45
Signed-off-by: Nan Li <nan.li@amlogic.com>
PD#142052: update video.c & enable vsync interrupt
1. the DEBUG_TMP is used to debug temporary
2. add meson-amvideom node is used to vsync the config in the dts
Change-Id: Id08e30e92fca45d2e07ac1321b834fcf437e3d0a
Signed-off-by: Nanxin Qin <nanxin.qin@amlogic.com>
PD#138714: add 32/64 bits compatibility support for dvb
1.add 32/64 bits compatibility support for dvb
2.add extension descrambler setting interface in CA
3.add DTV_TS_INPUT property
4.add CONFIG_AMLOGIC_DVB_COMPAT
Change-Id: Ifb48e1671446f3ac14db764b39ab1535950f177a
Signed-off-by: Ke Gong <ke.gong@amlogic.com>
PD#138714: warning messages like this
WARNING: modpopst: Found 3 section mismath(es).
Change-Id: I26bbdfc9ef04bf177dbab69a7383aaea142b7e37
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
PD#138714: led: add system gpio led driver support
add new configuration:
+CONFIG_AMLOGIC_LED=y
+CONFIG_AMLOGIC_LED_SYS=y
Change-Id: I34c3740eaf9efb02667d9e3d7e95ef8570e2c63c
Signed-off-by: Bo Yang <bo.yang@amlogic.com>
commit 619bd4a718 upstream.
Since the change in commit:
fd7a4bed18 ("sched, rt: Convert switched_{from, to}_rt() / prio_changed_rt() to balance callbacks")
... we don't reschedule a task under certain circumstances:
Lets say task-A, SCHED_OTHER, is running on CPU0 (and it may run only on
CPU0) and holds a PI lock. This task is removed from the CPU because it
used up its time slice and another SCHED_OTHER task is running. Task-B on
CPU1 runs at RT priority and asks for the lock owned by task-A. This
results in a priority boost for task-A. Task-B goes to sleep until the
lock has been made available. Task-A is already runnable (but not active),
so it receives no wake up.
The reality now is that task-A gets on the CPU once the scheduler decides
to remove the current task despite the fact that a high priority task is
enqueued and waiting. This may take a long time.
The desired behaviour is that CPU0 immediately reschedules after the
priority boost which made task-A the task with the lowest priority.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: fd7a4bed18 ("sched, rt: Convert switched_{from, to}_rt() prio_changed_rt() to balance callbacks")
Link: http://lkml.kernel.org/r/20170124144006.29821-1-bigeasy@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b53cf9815 upstream.
Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again. This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.
This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired. Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory. Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem. In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.
In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches. But this is a hard problem, and for now this bug must be fixed.
This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.
Fixes: b7236e21d5 ("ext4 crypto: reorganize how we store keys in the inode")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7195ee3120 upstream.
It's not clear what behaviour is sensible when doing partial write of
NT_METAG_RPIPE, so just don't bother.
This patch assumes that userspace will never rely on a partial SETREGSET
in this case, since it's not clear what should happen anyway.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d614fd58a2 upstream.
Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
to fill all the registers, the thread's old registers are preserved.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 502585c755 upstream.
regs_set() and regs_get() are vulnerable to an off-by-1 buffer overrun
if CONFIG_CPU_H8S is set, since this adds an extra entry to
register_offset[] but not to user_regs_struct.
So, iterate over user_regs_struct based on its actual size, not based on
the length of register_offset[].
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fb411b837b upstream.
gpr_set won't work correctly and can never have been tested, and the
correct behaviour is not clear due to the endianness-dependent task
layout.
So, just remove it. The core code will now return -EOPNOTSUPPORT when
trying to set NT_PRSTATUS on this architecture until/unless a correct
implementation is supplied.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fc8653228c upstream.
When init_vqs runs, virtio_balloon.stats is either uninitialized or
contains stale values. The host updates its state with garbage data
because it has no way of knowing that this is just a marker buffer
used for signaling.
This patch updates the stats before pushing the initial buffer.
Alternative fixes:
* Push an empty buffer in init_vqs. Not easily done with the current
virtio implementation and violates the spec "Driver MUST supply the
same subset of statistics in all buffers submitted to the statsq".
* Push a buffer with invalid tags in init_vqs. Violates the same
spec clause, plus "invalid tag" is not really defined.
Note: the spec says:
When using the legacy interface, the device SHOULD ignore all values in
the first buffer in the statsq supplied by the driver after device
initialization. Note: Historically, drivers supplied an uninitialized
buffer in the first buffer.
Unfortunately QEMU does not seem to implement the recommendation
even for the legacy interface.
Signed-off-by: Ladi Prosek <lprosek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f843ee6dd0 upstream.
Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to
wrapping issues. To ensure we are correctly ensuring that the two ESN
structures are the same size compare both the overall size as reported
by xfrm_replay_state_esn_len() and the internal length are the same.
CVE-2017-7184
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 677e806da4 upstream.
When a new xfrm state is created during an XFRM_MSG_NEWSA call we
validate the user supplied replay_esn to ensure that the size is valid
and to ensure that the replay_window size is within the allocated
buffer. However later it is possible to update this replay_esn via a
XFRM_MSG_NEWAE call. There we again validate the size of the supplied
buffer matches the existing state and if so inject the contents. We do
not at this point check that the replay_window is within the allocated
memory. This leads to out-of-bounds reads and writes triggered by
netlink packets. This leads to memory corruption and the potential for
priviledge escalation.
We already attempt to validate the incoming replay information in
xfrm_new_ae() via xfrm_replay_verify_len(). This confirms that the user
is not trying to change the size of the replay state buffer which
includes the replay_esn. It however does not check the replay_window
remains within that buffer. Add validation of the contained
replay_window.
CVE-2017-7184
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c282222a45 upstream.
Dmitry reports following splat:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 13059 Comm: syz-executor1 Not tainted 4.10.0-rc7-next-20170207 #1
[..]
spin_lock_bh include/linux/spinlock.h:304 [inline]
xfrm_policy_flush+0x32/0x470 net/xfrm/xfrm_policy.c:963
xfrm_policy_fini+0xbf/0x560 net/xfrm/xfrm_policy.c:3041
xfrm_net_init+0x79f/0x9e0 net/xfrm/xfrm_policy.c:3091
ops_init+0x10a/0x530 net/core/net_namespace.c:115
setup_net+0x2ed/0x690 net/core/net_namespace.c:291
copy_net_ns+0x26c/0x530 net/core/net_namespace.c:396
create_new_namespaces+0x409/0x860 kernel/nsproxy.c:106
unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
SYSC_unshare kernel/fork.c:2281 [inline]
Problem is that when we get error during xfrm_net_init we will call
xfrm_policy_fini which will acquire xfrm_policy_lock before it was
initialized. Just move it around so locks get set up first.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: 283bc9f35b ("xfrm: Namespacify xfrm state/policy locks")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
