27078 Commits

Author SHA1 Message Date
ggow 4045305775 config: austin: disable squashfs 2019-06-19 00:56:01 +01:00
ggow fbcaf3da81 lab126: Add idme driver 2019-05-24 12:36:32 +01:00
ggow fddef9b0e1 Add required changes for austin and ford 2019-04-21 09:20:06 +01:00
ggow 43fd89a550 Remove unused defconfigs and mt8127 machine types 2019-04-21 09:13:04 +01:00
Stricted d97274d81f set CONFIG_LOCALVERSION_AUTO 2018-04-18 19:26:13 +02:00
Stricted 1c2853c2c1 remove is_data_mounted crap entirely 2018-04-18 19:25:59 +02:00
Stricted 979dc3df78 store gtp_ref.bin and gtp_clk.bin on /cache
this is safe as the files are getting generated when they dont exist
2018-04-18 15:47:34 +02:00
Stricted 757110aa98 work around silly sysfs node requirement for working touch 2018-04-18 14:13:11 +02:00
Stricted 8ca3027ec7 fix section mismatch warnings 2018-03-24 13:51:10 +01:00
mttkrb e4c65dc707 Update tpd_debug.c
change include statement to prevent compiler-error because header file not found
2018-03-24 13:51:09 +01:00
Stricted 8c8e2e8863 get rid of drvgen 2018-03-24 13:51:09 +01:00
Stricted 9afc0d8b26 fix compilation after merge 2018-03-21 23:40:56 +01:00
Stricted 073b9047a0 Merge tag 'v3.10.107' into update
This is the 3.10.107 stable release
2018-03-21 23:07:35 +01:00
Stricted 47e5ca72da Merge tag 'v3.10.106' into update
This is the 3.10.106 stable release
2018-03-21 23:06:23 +01:00
Stricted ad957d335c Merge tag 'v3.10.105' into update
This is the 3.10.105 stable release
2018-03-21 23:00:38 +01:00
Stricted b9e7bc93d6 Merge tag 'v3.10.103' into update
This is the 3.10.103 stable release
2018-03-21 22:58:21 +01:00
Stricted a8732f92e3 Merge tag 'v3.10.102' into update
This is the 3.10.102 stable release
2018-03-21 22:54:09 +01:00
Stricted 647f2da1e2 Merge tag 'v3.10.98' into update
This is the 3.10.98 stable release
2018-03-21 22:51:37 +01:00
Stricted 9a68094070 Merge tag 'v3.10.94' into update
This is the 3.10.94 stable release
2018-03-21 22:49:45 +01:00
Stricted d50b84c473 Merge tag 'v3.10.91' into update
This is the 3.10.91 stable release
2018-03-21 22:48:36 +01:00
Stricted 3460ea59c6 Merge tag 'v3.10.87' into update
This is the 3.10.87 stable release
2018-03-21 22:47:22 +01:00
Stricted a03fb26067 Merge tag 'v3.10.84' into update
This is the 3.10.84 stable release
2018-03-21 22:46:36 +01:00
Stricted 81575b8770 Merge tag 'v3.10.83' into update
This is the 3.10.83 stable release
2018-03-21 22:46:32 +01:00
Stricted 5eab702925 Merge tag 'v3.10.80' into update
This is the 3.10.80 stable release
2018-03-21 22:45:22 +01:00
Stricted 705e3c2e81 Merge tag 'v3.10.79' into update
This is the 3.10.79 stable release
2018-03-21 22:44:42 +01:00
Stricted 9d35d890f3 Merge tag 'v3.10.78' into update
This is the 3.10.78 stable release
2018-03-21 22:44:38 +01:00
Stricted 9b13083065 Merge tag 'v3.10.77' into update
This is the 3.10.77 stable release
2018-03-21 22:44:34 +01:00
Stricted eff333fa3b Merge tag 'v3.10.73' into update
This is the 3.10.73 stable release
2018-03-21 22:41:03 +01:00
Stricted 5d8d08710c Merge tag 'v3.10.71' into update
This is the 3.10.71 stable release
2018-03-21 22:40:50 +01:00
Stricted 875966bda8 Merge tag 'v3.10.68' into update
This is the 3.10.68 stable release
2018-03-21 22:38:24 +01:00
Stricted b2d402e5a4 Merge tag 'v3.10.67' into update
This is the 3.10.67 stable release
2018-03-21 22:36:30 +01:00
Stricted 3219320124 Merge tag 'v3.10.66' into update
This is the 3.10.66 stable release
2018-03-21 22:36:27 +01:00
Stricted 90cb50b720 Merge tag 'v3.10.65' into update
This is the 3.10.65 stable release
2018-03-21 22:36:23 +01:00
Stricted 44c8e3c96a Merge tag 'v3.10.63' into update
This is the 3.10.63 stable release
2018-03-21 22:33:47 +01:00
Stricted 620f7405fd Merge tag 'v3.10.62' into update
This is the 3.10.62 stable release
2018-03-21 22:31:45 +01:00
Stricted 7887027a47 Merge tag 'v3.10.61' into update
This is the 3.10.61 stable release
2018-03-21 22:31:40 +01:00
Stricted 583be8778f Merge tag 'v3.10.59' into update
This is the 3.10.59 stable release
2018-03-21 22:31:29 +01:00
Stricted f29ec40f35 Merge tag 'v3.10.56' into update
This is the 3.10.56 stable release
2018-03-21 22:24:54 +01:00
Stricted b40a831c0f disable some mediatekl custom warnings 2018-03-21 15:41:24 +01:00
Diogo Ferreira 40712dd0bb Add an option to multiplex AP and STA on wlan0
This adds CONFIG_MTK_COMBO_AOSP_TETHERING_SUPPORT which, when enabled,
allows ap and wlan to co-exist in the same interface, as Android
expects.

Most of this functionality is also available (albeit not compilable broken)
under CFG_TC1_FEATURE but that has larger implications around the radio
and usb stack that we do not want to adopt.

Change-Id: Ib1d1be40566f1bb9ccc7be45b49ec8d1f3b3ba58
Ticket: PORRIDGE-30
2018-03-19 17:28:48 +01:00
Kees Cook 1a867a02ad ARM: add seccomp syscall
Wires up the new seccomp syscall.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>

Change-Id: I31a2d38b892e2cd81bf3998a916c7bb539a37767
2018-03-16 17:24:19 +01:00
Stricted 4b9e97964e import PULS_20180308 2018-03-13 20:30:12 +01:00
Stricted 6fa3eb70c0 import PULS_20160108 2018-03-13 20:29:02 +01:00
Hugh Dickins 1ad9a25dd0 mm: larger stack guard gap, between vmas
commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.

Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov <oleg@redhat.com>
Original-patch-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
[wt: backport to 4.11: adjust context]
[wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide]
[wt: backport to 4.4: adjust context ; drop ppc hugetlb_radix changes]
[wt: backport to 3.18: adjust context ; no FOLL_POPULATE ;
     s390 uses generic arch_get_unmapped_area()]
[wt: backport to 3.16: adjust context]
[wt: backport to 3.10: adjust context ; code logic in PARISC's
     arch_get_unmapped_area() wasn't found ; code inserted into
     expand_upwards() and expand_downwards() runs under anon_vma lock;
     changes for gup.c:faultin_page go to memory.c:__get_user_pages();
     included Hugh Dickins' fixes]
Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-06-21 15:42:43 +02:00
Fabien Parent 1c17617887 ARM: dts: da850-evm: fix read access to SPI flash
commit 43849785e1079f6606a31cb7fda92d1200849728 upstream.

Read access to the SPI flash are broken on da850-evm, i.e. the data
read is not what is actually programmed on the flash.
According to the datasheet for the M25P64 part present on the da850-evm,
if the SPI frequency is higher than 20MHz then the READ command is not
usable anymore and only the FAST_READ command can be used to read data.

This commit specifies in the DTS that we should use FAST_READ command
instead of the READ command.

Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Fabien Parent <fparent@baylibre.com>
[nsekhar@ti.com: subject line adjustment]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>

Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-06-20 14:04:08 +02:00
Mark Rutland d6797dd0b0 ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs
commit ddc37832a1349f474c4532de381498020ed71d31 upstream.

On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an
undefined instruction trap within write_wb_reg. This is because Scorpion
CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if
the core is not powered down. When DBGPRSR.SPD is set, breakpoint and
watchpoint registers are treated as undefined.

It's possible to trigger similar crashes later on from userspace, by
requesting the kernel to install a breakpoint or watchpoint, as we can
go idle at any point between the reset of the debug registers and their
later use. This has always been the case.

Given that this has always been broken, no-one has complained until now,
and there is no clear workaround, disable hardware breakpoints and
watchpoints on Scorpion to avoid these issues.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-06-20 14:04:08 +02:00
Julien Grall afeef476bb arm/xen: Use alloc_percpu rather than __alloc_percpu
commit 24d5373dda7c00a438d26016bce140299fae675e upstream.

The function xen_guest_init is using __alloc_percpu with an alignment
which are not power of two.

However, the percpu allocator never supported alignments which are not power
of two and has always behaved incorectly in thise case.

Commit 3ca45a4 "percpu: ensure requested alignment is power of two"
introduced a check which trigger a warning [1] when booting linux-next
on Xen. But in reality this bug was always present.

This can be fixed by replacing the call to __alloc_percpu with
alloc_percpu. The latter will use an alignment which are a power of two.

[1]

[    0.023921] illegal size (48) or align (48) for percpu allocation
[    0.024167] ------------[ cut here ]------------
[    0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
[    0.024584] Modules linked in:
[    0.024708]
[    0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.9.0-rc7-next-20161128 #473
[    0.025012] Hardware name: Foundation-v8A (DT)
[    0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
[    0.025351] PC is at pcpu_alloc+0x88/0x6c0
[    0.025490] LR is at pcpu_alloc+0x88/0x6c0
[    0.025624] pc : [<ffff00000818e678>] lr : [<ffff00000818e678>]
pstate: 60000045
[    0.025830] sp : ffff80003d847cd0
[    0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
[    0.026147] x27: 0000000000000000 x26: 0000000000000000
[    0.026348] x25: 0000000000000000 x24: 0000000000000000
[    0.026549] x23: 0000000000000000 x22: 00000000024000c0
[    0.026752] x21: ffff000008e97000 x20: 0000000000000000
[    0.026953] x19: 0000000000000030 x18: 0000000000000010
[    0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
[    0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
[    0.027573] x13: ffff000008f79c4d x12: 0000000000000041
[    0.027782] x11: 0000000000000006 x10: 0000000000000042
[    0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
[    0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
[    0.028419] x5 : 0000000000000005 x4 : 0000000000000000
[    0.028628] x3 : 0000000000000000 x2 : 000000000000017f
[    0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
[    0.029056]
[    0.029152] ---[ end trace 0000000000000000 ]---
[    0.029297] Call trace:
[    0.029403] Exception stack(0xffff80003d847b00 to
                               0xffff80003d847c30)
[    0.029621] 7b00: 0000000000000030 0001000000000000
ffff80003d847cd0 ffff00000818e678
[    0.029901] 7b20: 0000000000000002 0000000000000004
ffff000008f7c060 0000000000000035
[    0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
ffff80003d847bf0 ffff000008101778
[    0.030402] 7b60: 0000000000000030 0000000000000000
ffff000008e97000 00000000024000c0
[    0.030647] 7b80: 0000000000000000 0000000000000000
0000000000000000 0000000000000000
[    0.030895] 7ba0: 0000000000000035 ffff80003d870000
000000000000017f 0000000000000000
[    0.031144] 7bc0: 0000000000000000 0000000000000005
ffff000008f79c84 6120757063726570
[    0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
0000000000000042 0000000000000006
[    0.031643] 7c00: 0000000000000041 ffff000008f79c4d
ffff000088f79c3f 0000000000000006
[    0.031877] 7c20: 00000000deadbeef 0000000000000a3f
[    0.032051] [<ffff00000818e678>] pcpu_alloc+0x88/0x6c0
[    0.032229] [<ffff00000818ece8>] __alloc_percpu+0x18/0x20
[    0.032409] [<ffff000008d9606c>] xen_guest_init+0x174/0x2f4
[    0.032591] [<ffff0000080830f8>] do_one_initcall+0x38/0x130
[    0.032783] [<ffff000008d90c34>] kernel_init_freeable+0xe0/0x248
[    0.032995] [<ffff00000899a890>] kernel_init+0x10/0x100
[    0.033172] [<ffff000008082ec0>] ret_from_fork+0x10/0x50

Reported-by: Wei Chen <wei.chen@arm.com>
Link: https://lkml.org/lkml/2016/11/28/669
Signed-off-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-06-20 14:03:19 +02:00
Vladimir Zapolskiy bfac3620dc ARM: dts: imx31: fix AVIC base address
commit af92305e567b7f4c9cf48b9e46c1f48ec9ffb1fb upstream.

On i.MX31 AVIC interrupt controller base address is at 0x68000000.

The problem was shadowed by the AVIC driver, which takes the correct
base address from a SoC specific header file.

Fixes: d2a37b3d91 ("ARM i.MX31: Add devicetree support")
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-06-08 00:47:08 +02:00
Vladimir Zapolskiy 3e721e29e8 ARM: dts: imx31: move CCM device node to AIPS2 bus devices
commit 1f87aee6a2e55eda466a43ba6248a8b75eede153 upstream.

i.MX31 Clock Control Module controller is found on AIPS2 bus, move it
there from SPBA bus to avoid a conflict of device IO space mismatch.

Fixes: ef0e4a606f ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-06-08 00:47:08 +02:00
Dave Martin fcd0b4411d ARM: 8643/3: arm/ptrace: Preserve previous registers for short regset write
commit 228dbbfb5d77f8e047b2a1d78da14b7158433027 upstream.

Ensure that if userspace supplies insufficient data to
PTRACE_SETREGSET to fill all the registers, the thread's old
registers are preserved.

Fixes: 5be6f62b00 ("ARM: 6883/1: ptrace: Migrate to regsets framework")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-06-08 00:46:57 +02:00