[PATCH] csky: Fixup libgcc unwind error
From: Guo Ren
The struct rt_sigframe is also defined in libgcc/config/csky/linux-unwind.h
of gcc. Although there is no use for the first three word space, we must
keep them the same with linux-unwind.h for member position.
The BUG is found in glibc test with the tst-cancel02.
The BUG is from commit:bf2416829362 of linux-5.2-rc1 merge window.
Signed-off-by: Guo Ren
Signed-off-by: Mao Han
Cc: Arnd Bergmann
---
arch/csky/kernel/signal.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/csky/kernel/signal.c b/arch/csky/kernel/signal.c
index 04a43cf..d47a338 100644
--- a/arch/csky/kernel/signal.c
+++ b/arch/csky/kernel/signal.c
@@ -39,6 +39,11 @@ static int save_fpu_state(struct sigcontext __user *sc)
#endif
struct rt_sigframe {
+ /*
+* pad[3] is compatible with the same struct defined in
+* gcc/libgcc/config/csky/linux-unwind.h
+*/
+ int pad[3];
struct siginfo info;
struct ucontext uc;
};
--
2.7.4
Re: [PATCH 14/16] mm: move the powerpc hugepd code to mm/gup.c
On Tue, Jun 25, 2019 at 12:37:57PM -0700, Andrew Morton wrote: > On Tue, 25 Jun 2019 16:37:13 +0200 Christoph Hellwig wrote: > > > +static int gup_huge_pd(hugepd_t hugepd > > Naming nitlet: we have hugepd and we also have huge_pd. We have > hugepte and we also have huge_pte. It make things a bit hard to > remember and it would be nice to make it all consistent sometime. > > We're consistent with huge_pud and almost consistent with huge_pmd. > > To be fully consistent I guess we should make all of them have the > underscore. Or not have it. Either way is fine with me. Feel free to fix up per your preference.
Re: [RESEND PATCH v1 0/5] Solve postboot supplier cleanup and optimize probe ordering
On 6/25/19 9:30 PM, Sandeep Patil wrote: > On Tue, Jun 25, 2019 at 11:53:13AM +0800, Greg Kroah-Hartman wrote: >> On Mon, Jun 24, 2019 at 03:37:07PM -0700, Sandeep Patil wrote: >>> We are trying to make sure that all (most) drivers in an Aarch64 system can >>> be kernel modules for Android, like any other desktop system for >>> example. There are a number of problems we need to fix before that happens >>> ofcourse. >> >> I will argue that this is NOT an android-specific issue. If the goal of >> creating an arm64 kernel that will "just work" for a wide range of >> hardware configurations without rebuilding is going to happen, we need >> to solve this problem with DT. This goal was one of the original wishes >> of the arm64 development effort, let's not loose sight of it as >> obviously, this is not working properly just yet. > > I believe the proposed solution in this patch series is just that. I am not > sure what the alternatives are. The alternative suggested was to reuse Look at the responses from myself and from Rob to patch 0. No one responded to our comments. -Frank > pre-existing dt-bindings for dependency based probe re-ordering and > resolution. > > However, it seems we had no way to *really* check if these dependencies are > the real. So, a device may or may not actually depend on the other device for > probe / initialization when the dependency is mentioned in it's dt node. From > DT's point of view, there is no way to tell this .. > > I don't know how this is handled in x86. With DT, I don't see how we can do > this unless DT dependencies are _really_ tied with runtime dependencies (The > cycles would have been apparent if that was the case. > > Honestly, the "depends-on" property suggested here just piles on to the > existing state. So, it is somewhat doubling the exiting bindings. It says, > you must use depends-on property to define probe / initialization dependency. > The existing bindings like 'clock', 'interrupt', '*-supply' do not enforce > that right now, so you will have device nodes that have these bindings right > now but don't necessarily need them for successful probe for example. > >> >> It just seems that Android is the first one to actually try and >> implement that goal :) > > I guess :) > > - ssp > >> >> thanks, >> >> greg k-h >
Re: [Intel-wired-lan] Opportunistic S0ix blocked by e1000e when ethernet is in use
at 6:25 PM, Neftin, Sasha wrote: On 6/24/2019 18:06, Kai-Heng Feng wrote: at 19:56, Neftin, Sasha wrote: [Snipped] Current HW have a limitation. Please, try follow workaround on your platform: echo 3 > /sys/kernel/debug/pmc_core/ltr_ignore Yes, this does the trick. On 4.15 based kernel I can see the SoC enters PC10 but SLP_S0 is not asserted. On mainline kernel the SoC, PC10 is hit and SLP_S0 is asserted. Once SLP_S0 is asserted the SSH connection becomes really sluggish. >> S0ix support is under discussion with our architecture. We will try enable S0ix in our e1000e OOT driver as first step. Is it possible to add Dynamic LTR as an option so users and downstream distros can still benefit from it? As I said before, this is not a stable solution. No guarantee that HW will work as properly. Can you describe the symptom of "HW will work as properly”? Is this the sluggish connection I observed? Kai-Heng Kai-Heng Kai-Heng Kai-Heng ___ Intel-wired-lan mailing list intel-wired-...@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan Thanks Sasha
[PATCH] EDAC: Fix global-out-of-bounds write when setting edac_mc_poll_msec
Commit 9da21b1509d8 ("EDAC: Poll timeout cannot be zero, p2") assumes
edac_mc_poll_msec to be unsigned long, but the type of the variable still
remained as int. Setting edac_mc_poll_msec can trigger out-of-bounds
write.
Reproducer:
# echo 1001 > /sys/module/edac_core/parameters/edac_mc_poll_msec
KASAN report:
BUG: KASAN: global-out-of-bounds in edac_set_poll_msec+0x140/0x150
Write of size 8 at addr b91b2d00 by task bash/1996
CPU: 1 PID: 1996 Comm: bash Not tainted 5.2.0-rc6+ #23
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30
04/01/2014
Call Trace:
dump_stack+0xca/0x13e
print_address_description.cold+0x5/0x246
__kasan_report.cold+0x75/0x9a
? edac_set_poll_msec+0x140/0x150
kasan_report+0xe/0x20
edac_set_poll_msec+0x140/0x150
? dimmdev_location_show+0x30/0x30
? vfs_lock_file+0xe0/0xe0
? _raw_spin_lock+0x87/0xe0
param_attr_store+0x1b5/0x310
? param_array_set+0x4f0/0x4f0
module_attr_store+0x58/0x80
? module_attr_show+0x80/0x80
sysfs_kf_write+0x13d/0x1a0
kernfs_fop_write+0x2bc/0x460
? sysfs_kf_bin_read+0x270/0x270
? kernfs_notify+0x1f0/0x1f0
__vfs_write+0x81/0x100
vfs_write+0x1e1/0x560
ksys_write+0x126/0x250
? __ia32_sys_read+0xb0/0xb0
? do_syscall_64+0x1f/0x390
do_syscall_64+0xc1/0x390
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7fa7caa5e970
Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44
00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 04
RSP: 002b:7fff6acfdfe8 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 0005 RCX: 7fa7caa5e970
RDX: 0005 RSI: 00e95c08 RDI: 0001
RBP: 00e95c08 R08: 7fa7cad1e760 R09: 7fa7cb36a700
R10: 0073 R11: 0246 R12: 0005
R13: 0001 R14: 7fa7cad1d600 R15: 0005
The buggy address belongs to the variable:
edac_mc_poll_msec+0x0/0x40
Memory state around the buggy address:
b91b2c00: 00 00 00 00 fa fa fa fa 00 00 00 00 fa fa fa fa
b91b2c80: 00 00 00 00 fa fa fa fa 00 00 00 00 fa fa fa fa
>b91b2d00: 04 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
^
b91b2d80: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
b91b2e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Fix it by changing the type of edac_mc_poll_msec to unsigned int.
The reason why this patch adopts unsigned int rather than unsigned long
is msecs_to_jiffies() assumes arg to be unsigned int. We can avoid
integer conversion bugs and unsigned int will be large enough for
edac_mc_poll_msec.
Fixes: 9da21b1509d8 ("EDAC: Poll timeout cannot be zero, p2")
Signed-off-by: Eiichi Tsukata
---
drivers/edac/edac_mc_sysfs.c | 16
drivers/edac/edac_module.h | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 7c01e1cc030c..4386ea4b9b5a 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -26,7 +26,7 @@
static int edac_mc_log_ue = 1;
static int edac_mc_log_ce = 1;
static int edac_mc_panic_on_ue;
-static int edac_mc_poll_msec = 1000;
+static unsigned int edac_mc_poll_msec = 1000;
/* Getter functions for above */
int edac_mc_get_log_ue(void)
@@ -45,30 +45,30 @@ int edac_mc_get_panic_on_ue(void)
}
/* this is temporary */
-int edac_mc_get_poll_msec(void)
+unsigned int edac_mc_get_poll_msec(void)
{
return edac_mc_poll_msec;
}
static int edac_set_poll_msec(const char *val, const struct kernel_param *kp)
{
- unsigned long l;
+ unsigned int i;
int ret;
if (!val)
return -EINVAL;
- ret = kstrtoul(val, 0, );
+ ret = kstrtouint(val, 0, );
if (ret)
return ret;
- if (l < 1000)
+ if (i < 1000)
return -EINVAL;
- *((unsigned long *)kp->arg) = l;
+ *((unsigned int *)kp->arg) = i;
/* notify edac_mc engine to reset the poll period */
- edac_mc_reset_delay_period(l);
+ edac_mc_reset_delay_period(i);
return 0;
}
@@ -82,7 +82,7 @@ MODULE_PARM_DESC(edac_mc_log_ue,
module_param(edac_mc_log_ce, int, 0644);
MODULE_PARM_DESC(edac_mc_log_ce,
"Log correctable error to console: 0=off 1=on");
-module_param_call(edac_mc_poll_msec, edac_set_poll_msec, param_get_int,
+module_param_call(edac_mc_poll_msec, edac_set_poll_msec, param_get_uint,
_mc_poll_msec, 0644);
MODULE_PARM_DESC(edac_mc_poll_msec, "Polling period in milliseconds");
diff --git a/drivers/edac/edac_module.h b/drivers/edac/edac_module.h
index bc4b806dc9cc..b2f59ee76c22 100644
--- a/drivers/edac/edac_module.h
+++ b/drivers/edac/edac_module.h
@@ -36,7 +36,7 @@ extern int edac_mc_get_log_ue(void);
extern int edac_mc_get_log_ce(void);
extern int
[PATCH v2 0/2] Add MediaTek I3C master controller driver
This series are based on 5.2-rc1, we provide two patches to support MediaTek I3C master controller. Main changes compared to v1: --remove clock-div, let clock driver handle it --let sample_cnt and step_cnt start from two Qii Wang (2): dt-bindings: i3c: Document MediaTek I3C master bindings i3c: master: Add driver for MediaTek IP .../devicetree/bindings/i3c/mtk,i3c-master.txt | 47 + drivers/i3c/master/Kconfig | 10 + drivers/i3c/master/Makefile|1 + drivers/i3c/master/i3c-master-mtk.c| 1239 4 files changed, 1297 insertions(+) create mode 100644 Documentation/devicetree/bindings/i3c/mtk,i3c-master.txt create mode 100644 drivers/i3c/master/i3c-master-mtk.c -- 1.7.9.5
[PATCH v2 1/2] dt-bindings: i3c: Document MediaTek I3C master bindings
Document MediaTek I3C master DT bindings.
Signed-off-by: Qii Wang
---
.../devicetree/bindings/i3c/mtk,i3c-master.txt | 47
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/mtk,i3c-master.txt
diff --git a/Documentation/devicetree/bindings/i3c/mtk,i3c-master.txt
b/Documentation/devicetree/bindings/i3c/mtk,i3c-master.txt
new file mode 100644
index 000..3fd4f17
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/mtk,i3c-master.txt
@@ -0,0 +1,47 @@
+Bindings for MediaTek I3C master block
+=
+
+Required properties:
+
+- compatible: shall be "mediatek,i3c-master"
+- reg: physical base address of the controller and apdma base, length of
+ memory mapped region.
+- reg-names: should be "main" for controller and "dma" for apdma.
+- interrupts: interrupt number to the cpu.
+- clocks: clock name from clock manager.
+- clock-names: must include "main" and "dma".
+
+Mandatory properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- #address-cells: shall be set to 3
+- #size-cells: shall be set to 0
+
+Optional properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- i2c-scl-hz
+- i3c-scl-hz
+
+I3C device connected on the bus follow the generic description (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details).
+
+Example:
+
+ i3c0: i3c@1100d000 {
+ compatible = "mediatek,i3c-master";
+ reg = <0x1100d000 0x100>,
+ <0x11000300 0x80>;
+ reg-names = "main", "dma";
+ interrupts = ;
+ clocks = <_ck>, <_dma_ck>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-scl-hz = <10>;
+
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52 0x8010 0>;
+ };
+ };
--
1.7.9.5
[PATCH v2 2/2] i3c: master: Add driver for MediaTek IP
Add a driver for MediaTek I3C master IP.
Signed-off-by: Qii Wang
---
drivers/i3c/master/Kconfig | 10 +
drivers/i3c/master/Makefile |1 +
drivers/i3c/master/i3c-master-mtk.c | 1239 +++
3 files changed, 1250 insertions(+)
create mode 100644 drivers/i3c/master/i3c-master-mtk.c
diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
index 26c6b58..acc00d9 100644
--- a/drivers/i3c/master/Kconfig
+++ b/drivers/i3c/master/Kconfig
@@ -20,3 +20,13 @@ config DW_I3C_MASTER
This driver can also be built as a module. If so, the module
will be called dw-i3c-master.
+
+config MTK_I3C_MASTER
+ tristate "MediaTek I3C master driver"
+ depends on I3C
+ depends on HAS_IOMEM
+ depends on !(ALPHA || PARISC)
+ help
+ This selects the MediaTek(R) I3C master controller driver.
+ If you want to use MediaTek(R) I3C interface, say Y here.
+ If unsure, say N or M.
diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
index fc53939..fe7ccf5 100644
--- a/drivers/i3c/master/Makefile
+++ b/drivers/i3c/master/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_CDNS_I3C_MASTER) += i3c-master-cdns.o
obj-$(CONFIG_DW_I3C_MASTER)+= dw-i3c-master.o
+obj-$(CONFIG_MTK_I3C_MASTER) += i3c-master-mtk.o
diff --git a/drivers/i3c/master/i3c-master-mtk.c
b/drivers/i3c/master/i3c-master-mtk.c
new file mode 100644
index 000..3981149
--- /dev/null
+++ b/drivers/i3c/master/i3c-master-mtk.c
@@ -0,0 +1,1239 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 MediaTek Design Systems Inc.
+ *
+ * Author: Qii Wang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "i3c-master-mtk"
+
+#define SLAVE_ADDR 0x04
+#define INTR_MASK 0x08
+#define INTR_STAT 0x0c
+#define INTR_TRANSAC_COMP BIT(0)
+#define INTR_ACKERRGENMASK(2, 1)
+#define INTR_ARB_LOST BIT(3)
+#define INTR_RS_MULTI BIT(4)
+#define INTR_MAS_ERR BIT(8)
+#define INTR_ALL (INTR_MAS_ERR | INTR_ARB_LOST |\
+ INTR_ACKERR | INTR_TRANSAC_COMP)
+
+#define CONTROL0x10
+#define CONTROL_WRAPPERBIT(0)
+#define CONTROL_RS BIT(1)
+#define CONTROL_DMA_EN BIT(2)
+#define CONTROL_CLK_EXT_EN BIT(3)
+#define CONTROL_DIR_CHANGE BIT(4)
+#define CONTROL_ACKERR_DET_EN BIT(5)
+#define CONTROL_LEN_CHANGE BIT(6)
+#define CONTROL_DMAACK_EN BIT(8)
+#define CONTROL_ASYNC_MODE BIT(9)
+
+#define TRANSFER_LEN 0x14
+#define TRANSAC_LEN0x18
+#define TRANSAC_LEN_WRRD 0x0002
+#define TRANS_ONE_LEN 0x0001
+
+#define DELAY_LEN 0x1c
+#define DELAY_LEN_DEFAULT 0x000a
+
+#define TIMING 0x20
+#define TIMING_VALUE(sample_cnt, step_cnt) ({ \
+ typeof(sample_cnt) sample_cnt_ = (sample_cnt); \
+ typeof(step_cnt) step_cnt_ = (step_cnt); \
+ (((sample_cnt_) << 8) | (step_cnt_)); \
+})
+
+#define START 0x24
+#define START_EN BIT(0)
+#define START_MUL_TRIG BIT(14)
+#define START_MUL_CNFG BIT(15)
+
+#define EXT_CONF 0x28
+#define EXT_CONF_DEFAULT 0x0a1f
+
+#define LTIMING0x2c
+#define LTIMING_VALUE(sample_cnt, step_cnt) ({ \
+ typeof(sample_cnt) sample_cnt_ = (sample_cnt); \
+ typeof(step_cnt) step_cnt_ = (step_cnt); \
+ (((sample_cnt_) << 6) | (step_cnt_) | \
+ ((sample_cnt_) << 12) | ((step_cnt_) << 9)); \
+})
+
+#define HS 0x30
+#define HS_CLR_VALUE 0x
+#define HS_DEFAULT_VALUE 0x0083
+#define HS_VALUE(sample_cnt, step_cnt) ({ \
+ typeof(sample_cnt) sample_cnt_ = (sample_cnt); \
+ typeof(step_cnt) step_cnt_ = (step_cnt); \
+ (HS_DEFAULT_VALUE | \
+ ((sample_cnt_) << 12) | ((step_cnt_) << 8)); \
+})
+
+#define IO_CONFIG 0x34
+#define IO_CONFIG_PUSH_PULL0x
+
+#define FIFO_ADDR_CLR 0x38
+#define FIFO_CLR 0x0003
+
+#define MCU_INTR 0x40
+#define MCU_INTR_ENBIT(0)
+
+#define TRANSFER_LEN_AUX 0x44
+#define CLOCK_DIV 0x48
+#define CLOCK_DIV_DEFAULT ((INTER_CLK_DIV - 1) << 8 |\
+ (INTER_CLK_DIV - 1))
+
+#define SOFTRESET 0x50
+#define SOFT_RST BIT(0)
+
+#define TRAFFIC0x54
+#define TRAFFIC_DAA_EN BIT(4)
+#define TRAFFIC_TBIT BIT(7)
+#define TRAFFIC_HEAD_ONLY BIT(9)
+#define TRAFFIC_SKIP_SLV_ADDR BIT(10)
+#define TRAFFIC_HANDOFFBIT(14)
+
+#define DEF_DA 0x68
+#define DEF_DAA_SLV_PARITY BIT(8)
+
+#define SHAPE 0x6c
+#define SHAPE_T_STALL BIT(1)
+#define SHAPE_T_PARITY
[tip:x86/urgent] x86/mm: Handle physical-virtual alignment mismatch in phys_p4d_init()
Commit-ID: 432c833218dd0f75e7b56bd5e8658b72073158d2
Gitweb: https://git.kernel.org/tip/432c833218dd0f75e7b56bd5e8658b72073158d2
Author: Kirill A. Shutemov
AuthorDate: Mon, 24 Jun 2019 15:31:50 +0300
Committer: Thomas Gleixner
CommitDate: Wed, 26 Jun 2019 07:25:09 +0200
x86/mm: Handle physical-virtual alignment mismatch in phys_p4d_init()
Kyle has reported occasional crashes when booting a kernel in 5-level
paging mode with KASLR enabled:
WARNING: CPU: 0 PID: 0 at arch/x86/mm/init_64.c:87 phys_p4d_init+0x1d4/0x1ea
RIP: 0010:phys_p4d_init+0x1d4/0x1ea
Call Trace:
__kernel_physical_mapping_init+0x10a/0x35c
kernel_physical_mapping_init+0xe/0x10
init_memory_mapping+0x1aa/0x3b0
init_range_memory_mapping+0xc8/0x116
init_mem_mapping+0x225/0x2eb
setup_arch+0x6ff/0xcf5
start_kernel+0x64/0x53b
? copy_bootdata+0x1f/0xce
x86_64_start_reservations+0x24/0x26
x86_64_start_kernel+0x8a/0x8d
secondary_startup_64+0xb6/0xc0
which causes later:
BUG: unable to handle page fault for address: ff484d019580eff8
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
BAD
Oops: [#1] SMP NOPTI
RIP: 0010:fill_pud+0x13/0x130
Call Trace:
set_pte_vaddr_p4d+0x2e/0x50
set_pte_vaddr+0x6f/0xb0
__native_set_fixmap+0x28/0x40
native_set_fixmap+0x39/0x70
register_lapic_address+0x49/0xb6
early_acpi_boot_init+0xa5/0xde
setup_arch+0x944/0xcf5
start_kernel+0x64/0x53b
Kyle bisected the issue to commit b569c1843498 ("x86/mm/KASLR: Reduce
randomization granularity for 5-level paging to 1GB")
Before this commit PAGE_OFFSET was always aligned to P4D_SIZE when booting
5-level paging mode. But now only PUD_SIZE alignment is guaranteed.
In the case I was able to reproduce the following vaddr/paddr values were
observed in phys_p4d_init():
Iteration vaddr paddr
1 0xff4228027fe00x033fe0
2 0xff42287f40000x80
'vaddr' in both cases belongs to the same p4d entry.
But due to the original assumption that PAGE_OFFSET is aligned to P4D_SIZE
this overlap cannot be handled correctly. The code assumes strictly aligned
entries and unconditionally increments the index into the P4D table, which
creates false duplicate entries. Once the index reaches the end, the last
entry in the page table is missing.
Aside of that the 'paddr >= paddr_end' condition can evaluate wrong which
causes an P4D entry to be cleared incorrectly.
Change the loop in phys_p4d_init() to walk purely based on virtual
addresses like __kernel_physical_mapping_init() does. This makes it work
correctly with unaligned virtual addresses.
Fixes: b569c1843498 ("x86/mm/KASLR: Reduce randomization granularity for
5-level paging to 1GB")
Reported-by: Kyle Pelton
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Thomas Gleixner
Tested-by: Kyle Pelton
Acked-by: Baoquan He
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Link:
https://lkml.kernel.org/r/20190624123150.920-1-kirill.shute...@linux.intel.com
---
arch/x86/mm/init_64.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 693aaf28d5fe..0f01c7b1d217 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -671,23 +671,25 @@ static unsigned long __meminit
phys_p4d_init(p4d_t *p4d_page, unsigned long paddr, unsigned long paddr_end,
unsigned long page_size_mask, bool init)
{
- unsigned long paddr_next, paddr_last = paddr_end;
- unsigned long vaddr = (unsigned long)__va(paddr);
- int i = p4d_index(vaddr);
+ unsigned long vaddr, vaddr_end, vaddr_next, paddr_next, paddr_last;
+
+ paddr_last = paddr_end;
+ vaddr = (unsigned long)__va(paddr);
+ vaddr_end = (unsigned long)__va(paddr_end);
if (!pgtable_l5_enabled())
return phys_pud_init((pud_t *) p4d_page, paddr, paddr_end,
page_size_mask, init);
- for (; i < PTRS_PER_P4D; i++, paddr = paddr_next) {
- p4d_t *p4d;
+ for (; vaddr < vaddr_end; vaddr = vaddr_next) {
+ p4d_t *p4d = p4d_page + p4d_index(vaddr);
pud_t *pud;
- vaddr = (unsigned long)__va(paddr);
- p4d = p4d_page + p4d_index(vaddr);
- paddr_next = (paddr & P4D_MASK) + P4D_SIZE;
+ vaddr_next = (vaddr & P4D_MASK) + P4D_SIZE;
+ paddr = __pa(vaddr);
if (paddr >= paddr_end) {
+ paddr_next = __pa(vaddr_next);
if (!after_bootmem &&
!e820__mapped_any(paddr & P4D_MASK, paddr_next,
E820_TYPE_RAM) &&
@@ -699,13 +701,13 @@ phys_p4d_init(p4d_t *p4d_page, unsigned long paddr,
unsigned long paddr_end,
[tip:x86/urgent] x86/boot/64: Add missing fixup_pointer() for next_early_pgt access
Commit-ID: c1887159eb48ba40e775584cfb2a443962cf1a05
Gitweb: https://git.kernel.org/tip/c1887159eb48ba40e775584cfb2a443962cf1a05
Author: Kirill A. Shutemov
AuthorDate: Thu, 20 Jun 2019 14:24:22 +0300
Committer: Thomas Gleixner
CommitDate: Wed, 26 Jun 2019 07:25:09 +0200
x86/boot/64: Add missing fixup_pointer() for next_early_pgt access
__startup_64() uses fixup_pointer() to access global variables in a
position-independent fashion. Access to next_early_pgt was wrapped into the
helper, but one instance in the 5-level paging branch was missed.
GCC generates a R_X86_64_PC32 PC-relative relocation for the access which
doesn't trigger the issue, but Clang emmits a R_X86_64_32S which leads to
an invalid memory access and system reboot.
Fixes: 187e91fe5e91 ("x86/boot/64/clang: Use fixup_pointer() to access
'next_early_pgt'")
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Thomas Gleixner
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Alexander Potapenko
Link:
https://lkml.kernel.org/r/20190620112422.29264-1-kirill.shute...@linux.intel.com
---
arch/x86/kernel/head64.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 7df5bce4e1be..29ffa495bd1c 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -184,7 +184,8 @@ unsigned long __head __startup_64(unsigned long physaddr,
pgtable_flags = _KERNPG_TABLE_NOENC + sme_get_me_mask();
if (la57) {
- p4d = fixup_pointer(early_dynamic_pgts[next_early_pgt++],
physaddr);
+ p4d = fixup_pointer(early_dynamic_pgts[(*next_pgt_ptr)++],
+ physaddr);
i = (physaddr >> PGDIR_SHIFT) % PTRS_PER_PGD;
pgd[i + 0] = (pgdval_t)p4d + pgtable_flags;
[tip:x86/urgent] x86/boot/64: Fix crash if kernel image crosses page table boundary
Commit-ID: 81c7ed296dcd02bc0b4488246d040e03e633737a
Gitweb: https://git.kernel.org/tip/81c7ed296dcd02bc0b4488246d040e03e633737a
Author: Kirill A. Shutemov
AuthorDate: Thu, 20 Jun 2019 14:23:45 +0300
Committer: Thomas Gleixner
CommitDate: Wed, 26 Jun 2019 07:25:09 +0200
x86/boot/64: Fix crash if kernel image crosses page table boundary
A kernel which boots in 5-level paging mode crashes in a small percentage
of cases if KASLR is enabled.
This issue was tracked down to the case when the kernel image unpacks in a
way that it crosses an 1G boundary. The crash is caused by an overrun of
the PMD page table in __startup_64() and corruption of P4D page table
allocated next to it. This particular issue is not visible with 4-level
paging as P4D page tables are not used.
But the P4D and the PUD calculation have similar problems.
The PMD index calculation is wrong due to operator precedence, which fails
to confine the PMDs in the PMD array on wrap around.
The P4D calculation for 5-level paging and the PUD calculation calculate
the first index correctly, but then blindly increment it which causes the
same issue when a kernel image is located across a 512G and for 5-level
paging across a 46T boundary.
This wrap around mishandling was introduced when these parts moved from
assembly to C.
Restore it to the correct behaviour.
Fixes: c88d71508e36 ("x86/boot/64: Rewrite startup_64() in C")
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Thomas Gleixner
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Link:
https://lkml.kernel.org/r/20190620112345.28833-1-kirill.shute...@linux.intel.com
---
arch/x86/kernel/head64.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 16b1cbd3a61e..7df5bce4e1be 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -190,18 +190,18 @@ unsigned long __head __startup_64(unsigned long physaddr,
pgd[i + 0] = (pgdval_t)p4d + pgtable_flags;
pgd[i + 1] = (pgdval_t)p4d + pgtable_flags;
- i = (physaddr >> P4D_SHIFT) % PTRS_PER_P4D;
- p4d[i + 0] = (pgdval_t)pud + pgtable_flags;
- p4d[i + 1] = (pgdval_t)pud + pgtable_flags;
+ i = physaddr >> P4D_SHIFT;
+ p4d[(i + 0) % PTRS_PER_P4D] = (pgdval_t)pud + pgtable_flags;
+ p4d[(i + 1) % PTRS_PER_P4D] = (pgdval_t)pud + pgtable_flags;
} else {
i = (physaddr >> PGDIR_SHIFT) % PTRS_PER_PGD;
pgd[i + 0] = (pgdval_t)pud + pgtable_flags;
pgd[i + 1] = (pgdval_t)pud + pgtable_flags;
}
- i = (physaddr >> PUD_SHIFT) % PTRS_PER_PUD;
- pud[i + 0] = (pudval_t)pmd + pgtable_flags;
- pud[i + 1] = (pudval_t)pmd + pgtable_flags;
+ i = physaddr >> PUD_SHIFT;
+ pud[(i + 0) % PTRS_PER_PUD] = (pudval_t)pmd + pgtable_flags;
+ pud[(i + 1) % PTRS_PER_PUD] = (pudval_t)pmd + pgtable_flags;
pmd_entry = __PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL;
/* Filter out unsupported __PAGE_KERNEL_* bits: */
@@ -211,8 +211,9 @@ unsigned long __head __startup_64(unsigned long physaddr,
pmd_entry += physaddr;
for (i = 0; i < DIV_ROUND_UP(_end - _text, PMD_SIZE); i++) {
- int idx = i + (physaddr >> PMD_SHIFT) % PTRS_PER_PMD;
- pmd[idx] = pmd_entry + i * PMD_SIZE;
+ int idx = i + (physaddr >> PMD_SHIFT);
+
+ pmd[idx % PTRS_PER_PMD] = pmd_entry + i * PMD_SIZE;
}
/*
Re: [PATCH RESEND 6/8] parisc: Use mmap_base, not mmap_legacy_base, as low_limit for bottom-up mmap
On 6/25/19 10:09 AM, Helge Deller wrote:
On 20.06.19 07:03, Alexandre Ghiti wrote:
Bottom-up mmap scheme is used twice:
- for legacy mode, in which mmap_legacy_base and mmap_base are equal.
- in case of mmap failure in top-down mode, where there is no need to go
through the whole address space again for the bottom-up fallback: the goal
of this fallback is to find, as a last resort, space between the top-down
mmap base and the stack, which is the only place not covered by the
top-down mmap.
Then this commit removes the usage of mmap_legacy_base field from parisc
code.
Signed-off-by: Alexandre Ghiti
Boot-tested on parisc and seems to work nicely, thus:
Acked-by: Helge Deller
Thanks Helge,
Alex
Helge
---
arch/parisc/kernel/sys_parisc.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index 5d458a44b09c..e987f3a8eb0b 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -119,7 +119,7 @@ unsigned long arch_get_unmapped_area(struct file *filp,
unsigned long addr,
info.flags = 0;
info.length = len;
- info.low_limit = mm->mmap_legacy_base;
+ info.low_limit = mm->mmap_base;
info.high_limit = mmap_upper_limit(NULL);
info.align_mask = last_mmap ? (PAGE_MASK & (SHM_COLOUR - 1)) : 0;
info.align_offset = shared_align_offset(last_mmap, pgoff);
@@ -240,13 +240,11 @@ static unsigned long mmap_legacy_base(void)
*/
void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
{
- mm->mmap_legacy_base = mmap_legacy_base();
- mm->mmap_base = mmap_upper_limit(rlim_stack);
-
if (mmap_is_legacy()) {
- mm->mmap_base = mm->mmap_legacy_base;
+ mm->mmap_base = mmap_legacy_base();
mm->get_unmapped_area = arch_get_unmapped_area;
} else {
+ mm->mmap_base = mmap_upper_limit(rlim_stack);
mm->get_unmapped_area = arch_get_unmapped_area_topdown;
}
}
Re: linux-next: Signed-off-by missing for commit in the tip tree
On Wed, 26 Jun 2019, Stephen Rothwell wrote:
>
> 53d87b37a2a4 ("arm64: compat: No need for pre-ARMv7 barriers on an ARMv8
> system")
> b4b12aca00d5 ("arm64: vdso: Remove unnecessary asm-offsets.c definitions")
> 4d33ebb02c45 ("vdso: Remove superfluous #ifdef __KERNEL__ in
> vdso/datapage.h")
>
> are missing a Signed-off-by from their committer.
Oops.
Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs
On Tue, Jun 25, 2019 at 08:46:26PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jun 25, 2019 at 01:27:46PM -0700, Nathan Chancellor escreveu:
> > On Tue, Jun 25, 2019 at 09:53:09PM +0200, Thomas Gleixner wrote:
> > > On Tue, 25 Jun 2019, Nathan Chancellor wrote:
> > > > On Tue, Jun 25, 2019 at 10:12:42AM -0700, Kees Cook wrote:
> > > > > On Tue, Jun 25, 2019 at 09:18:46AM +0200, Peter Zijlstra wrote:
> > > > > > Can it build a kernel without patches yet? That is, why should I
> > > > > > care
> > > > > > what LLVM does?
> > > > >
> > > > > Yes. LLVM trunk builds and boots x86 now. As for distro availability,
> > > > > AIUI, the asm-goto feature missed the 9.0 LLVM branch point, so it'll
> > > > > appear in the following release.
> > > > >
> > > > > --
> > > > > Kees Cook
> > > >
> > > > I don't think that's right. LLVM 9 hasn't been branched yet so it should
> > > > make it in.
> > > >
> > > > http://lists.llvm.org/pipermail/llvm-dev/2019-June/133155.html
> > > >
> > > > If anyone wants to play around with it before then, we wrote a
> > > > self-contained script that will build an LLVM toolchain suitable for
> > > > kernel development:
> > > >
> > > > https://github.com/ClangBuiltLinux/tc-build
> > >
> > > Useful!
> > >
> > > But can the script please check for a minimal clang version required to
> > > build that thing.
> > >
> > > The default clang-3.8 which is installed on Debian stretch explodes. The
> > > 6.0 variant from backports works as advertised.
> > >
> >
> > Hmmm interesting, I test a lot of different distros using Docker
> > containers to make sure the script works universally and that includes
> > Debian stretch, which is the stress tester because all of the packages
> > are older.
>
> Interesting, I've been building tools/perf, tools/{lib,arch/include},
> etc with lots of clang versions for quite a while, all in containers,
> using podman:
>
Huh, interesting, I'm going to have to check that out (first time I have
heard of podman).
If anyone cares to see it, here is my little crude script:
https://github.com/nathanchance/scripts/blob/d8cfcc05fc50453503d48e32767f24dfac82dcd4/funcs/cbl#L693-L776
Cheers,
Nathan
>
> The first ones are container based builds of tools/perf with and without
> libelf
> support. Where clang is available, it is also used to build perf with/without
> libelf, and building with LIBCLANGLLVM=1 (built-in clang) with gcc and clang
> when clang and its devel libraries are installed.
>
> Several are cross builds, the ones with -x-ARCH and the android one, and those
> may not have all the features built, due to lack of multi-arch devel packages,
> available and being used so far on just a few, like
> debian:experimental-x-{arm64,mipsel}.
>
> $ export PERF_TARBALL=http://192.168.124.1/perf/perf-5.2.0-rc4.tar.xz
> $ dm
>1 alpine:3.4: Ok gcc (Alpine 5.3.0) 5.3.0, clang
> version 3.8.0 (tags/RELEASE_380/final)
>2 alpine:3.5: Ok gcc (Alpine 6.2.1) 6.2.1 20160822,
> clang version 3.8.1 (tags/RELEASE_381/final)
>3 alpine:3.6: Ok gcc (Alpine 6.3.0) 6.3.0, clang
> version 4.0.0 (tags/RELEASE_400/final)
>4 alpine:3.7: Ok gcc (Alpine 6.4.0) 6.4.0, Alpine
> clang version 5.0.0 (tags/RELEASE_500/final) (based on LLVM 5.0.0)
>5 alpine:3.8: Ok gcc (Alpine 6.4.0) 6.4.0, Alpine
> clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1)
>6 alpine:3.9: Ok gcc (Alpine 8.3.0) 8.3.0, Alpine
> clang version 5.0.1 (tags/RELEASE_502/final) (based on LLVM 5.0.1)
>7 alpine:edge : Ok gcc (Alpine 8.3.0) 8.3.0, Alpine
> clang version 7.0.1 (tags/RELEASE_701/final) (based on LLVM 7.0.1)
>8 amazonlinux:1 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat
> 7.2.1-2), clang version 3.6.2 (tags/RELEASE_362/final)
>9 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat
> 7.3.1-5), clang version 7.0.1 (Amazon Linux 2 7.0.1-1.amzn2.0.2)
> 10 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC)
> 4.9.x 20150123 (prerelease)
> 11 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC)
> 4.9.x 20150123 (prerelease)
> 12 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat
> 4.1.2-55)
> 13 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat
> 4.4.7-23)
> 14 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat
> 4.8.5-36)
> 15 clearlinux:latest : Ok gcc (Clear Linux OS for Intel
> Architecture) 9.1.1 20190611 gcc-9-branch@272162
> 16 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u2) 4.9.2,
> Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
> 17 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0
> 20170516, clang version 3.8.1-24
Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs
On Tue, Jun 25, 2019 at 11:47:06PM +0200, Thomas Gleixner wrote:
> On Tue, 25 Jun 2019, Nathan Chancellor wrote:
> > On Tue, Jun 25, 2019 at 09:53:09PM +0200, Thomas Gleixner wrote:
> > >
> > > But can the script please check for a minimal clang version required to
> > > build that thing.
> > >
> > > The default clang-3.8 which is installed on Debian stretch explodes. The
> > > 6.0 variant from backports works as advertised.
> > >
> >
> > Hmmm interesting, I test a lot of different distros using Docker
> > containers to make sure the script works universally and that includes
> > Debian stretch, which is the stress tester because all of the packages
> > are older. I install the following packages then run the following
> > command and it works fine for me (just tested):
> >
> > $ apt update && apt install -y --no-install-recommends ca-certificates \
> > ccache clang cmake curl file gcc g++ git make ninja-build python3 \
> > texinfo zlib1g-dev
> > $ ./build-llvm.py
> >
> > If you could give me a build log, I'd be happy to look into it and see
> > what I can do.
>
> I can produce one tomorrow.
>
Great, thank you!
> > > Kernel builds with the new shiny compiler. Jump labels seem to be enabled.
> > >
> > > It complains about a few type conversions:
> > >
> > > arch/x86/kvm/mmu.c:4596:39: warning: implicit conversion from 'int' to
> > > 'u8' (aka 'unsigned char') changes value from -205 to 51
> > > [-Wconstant-conversion]
> > > u8 wf = (pfec & PFERR_WRITE_MASK) ? ~w : 0;
> > >~~ ^~
> > >
> >
> > Yes, there was a patch sent to try and fix this but it was rejected by
> > the maintainers:
> >
> > https://github.com/ClangBuiltLinux/linux/issues/95
> >
> > https://lore.kernel.org/lkml/20180619192504.180479-1-...@chromium.org/
>
> Just looked through it. I don't think it's an outright reject. Paolo was
> not totally against it and then the whole discussion degraded into bikeshed
> painting and bitching about compiler error messaged. Try again or should I?
>
Might be worth having you chime in, given that is the only instance of
that type of warning that I see in my set of builds (I fixed the rest:
https://github.com/ClangBuiltLinux/linux/issues?q=label%3A-Wconstant-conversion)
> > > but it also makes objtool unhappy:
> > >
> > > arch/x86/events/intel/core.o: warning: objtool:
> > > intel_pmu_nhm_workaround()+0xb3: unreachable
> instruction
> > > kernel/fork.o: warning: objtool: free_thread_stack()+0x126: unreachable
> > > instruction
> > > mm/workingset.o: warning: objtool: count_shadow_nodes()+0x11f:
> > > unreachable instruction
> > > arch/x86/kernel/cpu/mtrr/generic.o: warning: objtool:
> > > get_fixed_ranges()+0x9b: unreachable
> instruction
> > > arch/x86/kernel/platform-quirks.o: warning: objtool:
> > > x86_early_init_platform_quirks()+0x84:
> unreachable instruction
> > > drivers/iommu/irq_remapping.o: warning: objtool:
> > > irq_remap_enable_fault_handling()+0x1d:
> unreachable instruction
>
> > Unfortunately, we have quite a few of those outstanding, it's probably
> > time to start really taking a look at them:
> >
> > https://github.com/ClangBuiltLinux/linux/labels/objtool
>
> I just checked two of them in the disassembly. In both cases it's jump
> label related. Here is one:
>
> asm volatile("1: rdmsr\n"
> 410: b9 59 02 00 00 mov$0x259,%ecx
> 415: 0f 32 rdmsr
> 417: 49 89 c6mov%rax,%r14
> 41a: 48 89 d3mov%rdx,%rbx
> return EAX_EDX_VAL(val, low, high);
> 41d: 48 c1 e3 20 shl$0x20,%rbx
> 421: 48 09 c3or %rax,%rbx
> 424: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> 429: eb 0f jmp43a
> do_trace_read_msr(msr, val, 0);
> 42b: bf 59 02 00 00 mov$0x259,%edi <--- "unreachable"
> 430: 48 89 demov%rbx,%rsi
> 433: 31 d2 xor%edx,%edx
> 435: e8 00 00 00 00 callq 43a
> 43a: 44 89 35 00 00 00 00mov%r14d,0x0(%rip)# 441
>
>
> Interestingly enough there are some more hunks of the same pattern in that
> function which look all the same. Those are not upsetting objtool. Josh
> might give an hint where to stare at.
>
> Just for the fun of it I looked at the GCC output of the same file. It
> takes a different apporach:
>
> asm volatile("1: rdmsr\n"
> c70: b9 59 02 00 00 mov$0x259,%ecx
> c75: 0f 32 rdmsr
> return EAX_EDX_VAL(val, low, high);
> c77: 48 c1 e2 20 shl$0x20,%rdx
> c7b: 48 89 d3mov%rdx,%rbx
> c7e: 48 09 c3or %rax,%rbx
> c81: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> c86: 48 89 1d 00 00 00 00mov%rbx,0x0(%rip)# c8d
>
>
> and the tracing code is completely out of line:
>
>
[PATCH V3 0/2] sched/fair: Fallback to sched-idle CPU in absence of idle CPUs
Hi, We try to find an idle CPU to run the next task, but in case we don't find an idle CPU it is better to pick a CPU which will run the task the soonest, for performance reason. A CPU which isn't idle but has only SCHED_IDLE activity queued on it should be a good target based on this criteria as any normal fair task will most likely preempt the currently running SCHED_IDLE task immediately. In fact, choosing a SCHED_IDLE CPU over a fully idle one shall give better results as it should be able to run the task sooner than an idle CPU (which requires to be woken up from an idle state). This patchset updates both fast and slow paths with this optimization. Testing is done with the help of rt-app currently and here are the details: - Tested on Octacore Hikey platform (all CPUs change frequency together). - rt-app json [1] creates few tasks and we monitor the scheduling latency for them by looking at "wu_lat" field (usec). - The histograms are created using https://github.com/adkein/textogram: textogram -a 0 -z 1000 -n 10 - the stats are accumulated using: https://github.com/nferraz/st - NOTE: The % values shown don't add up, just look at total numbers instead Test 1: Create 8 CFS tasks (no SCHED_IDLE tasks) without this patchset: 0 - 100 : ## 72% (3688) 100 - 200 : 24% (1253) 200 - 300 : ##2% (149) 300 - 400 : 0% (22) 400 - 500 : 0% (1) 500 - 600 : 0% (3) 600 - 700 : 0% (1) 700 - 800 : 0% (1) 800 - 900 : 900 - 1000 : 0% (1) >1000 : 0% (17) N min max sum meanstddev 51360 2452535985 104.358 104.585 Test 2: Create 8 CFS tasks and 5 SCHED_IDLE tasks: A. Without sched-idle patchset: 0 - 100 : ## 88% (3102) 100 - 200 : ##4% (148) 200 - 300 : 1% (41) 300 - 400 : 0% (27) 400 - 500 : 0% (33) 500 - 600 : 0% (32) 600 - 700 : 1% (36) 700 - 800 : 0% (27) 800 - 900 : 0% (19) 900 - 1000 : 0% (26) >1000 : 34% (1218) N min max sum meanstddev 47100 67664 5.25956e+06 1116.68 2315.09 B. With sched-idle patchset: 0 - 100 : ## 99% (5042) 100 - 200 : 0% (8) 200 - 300 : 300 - 400 : 400 - 500 : 0% (2) 500 - 600 : 0% (1) 600 - 700 : 700 - 800 : 0% (1) 800 - 900 : 0% (1) 900 - 1000 : >1000 : 0% (40) N min max sum meanstddev 50950 7773523170 102.683 475.482 The mean latency dropped to 10% and the stddev to around 25% with this patchset. @Song: Can you please see if the slowpath changes bring any further improvements in your test case ? V2->V3: - Removed a pointless branch from 1/2 (PeterZ). - Removed the RFC tags as patches are getting in better shape now. - Updated the slow path as well, earlier versions only supported fast paths. - Rebased over latest tip/master, fixed rebase conflicts. - Improved commit logs. -- viresh [1] https://pastebin.com/TMHGGBxD Viresh Kumar (2): sched: Start tracking SCHED_IDLE tasks count in cfs_rq sched/fair: Fallback to sched-idle CPU if idle CPU isn't found kernel/sched/fair.c | 57 ++-- kernel/sched/sched.h | 2 ++ 2 files changed, 47 insertions(+), 12 deletions(-) -- 2.21.0.rc0.269.g1a574e7a288b
[PATCH V3 2/2] sched/fair: Fallback to sched-idle CPU if idle CPU isn't found
We try to find an idle CPU to run the next task, but in case we don't
find an idle CPU it is better to pick a CPU which will run the task the
soonest, for performance reason.
A CPU which isn't idle but has only SCHED_IDLE activity queued on it
should be a good target based on this criteria as any normal fair task
will most likely preempt the currently running SCHED_IDLE task
immediately. In fact, choosing a SCHED_IDLE CPU over a fully idle one
shall give better results as it should be able to run the task sooner
than an idle CPU (which requires to be woken up from an idle state).
This patch updates both fast and slow paths with this optimization.
Signed-off-by: Viresh Kumar
---
kernel/sched/fair.c | 43 +--
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 1277adc3e7ed..2e0527fd468c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5376,6 +5376,15 @@ static struct {
#endif /* CONFIG_NO_HZ_COMMON */
+/* CPU only has SCHED_IDLE tasks enqueued */
+static int sched_idle_cpu(int cpu)
+{
+ struct rq *rq = cpu_rq(cpu);
+
+ return unlikely(rq->nr_running == rq->cfs.idle_h_nr_running &&
+ rq->nr_running);
+}
+
static unsigned long cpu_runnable_load(struct rq *rq)
{
return cfs_rq_runnable_load_avg(>cfs);
@@ -5698,7 +5707,7 @@ find_idlest_group_cpu(struct sched_group *group, struct
task_struct *p, int this
unsigned int min_exit_latency = UINT_MAX;
u64 latest_idle_timestamp = 0;
int least_loaded_cpu = this_cpu;
- int shallowest_idle_cpu = -1;
+ int shallowest_idle_cpu = -1, si_cpu = -1;
int i;
/* Check if we have any choice: */
@@ -5729,7 +5738,12 @@ find_idlest_group_cpu(struct sched_group *group, struct
task_struct *p, int this
latest_idle_timestamp = rq->idle_stamp;
shallowest_idle_cpu = i;
}
- } else if (shallowest_idle_cpu == -1) {
+ } else if (shallowest_idle_cpu == -1 && si_cpu == -1) {
+ if (sched_idle_cpu(i)) {
+ si_cpu = i;
+ continue;
+ }
+
load = cpu_runnable_load(cpu_rq(i));
if (load < min_load) {
min_load = load;
@@ -5738,7 +5752,11 @@ find_idlest_group_cpu(struct sched_group *group, struct
task_struct *p, int this
}
}
- return shallowest_idle_cpu != -1 ? shallowest_idle_cpu :
least_loaded_cpu;
+ if (shallowest_idle_cpu != -1)
+ return shallowest_idle_cpu;
+ if (si_cpu != -1)
+ return si_cpu;
+ return least_loaded_cpu;
}
static inline int find_idlest_cpu(struct sched_domain *sd, struct task_struct
*p,
@@ -5891,7 +5909,7 @@ static int select_idle_core(struct task_struct *p, struct
sched_domain *sd, int
*/
static int select_idle_smt(struct task_struct *p, int target)
{
- int cpu;
+ int cpu, si_cpu = -1;
if (!static_branch_likely(_smt_present))
return -1;
@@ -5901,9 +5919,11 @@ static int select_idle_smt(struct task_struct *p, int
target)
continue;
if (available_idle_cpu(cpu))
return cpu;
+ if (si_cpu == -1 && sched_idle_cpu(cpu))
+ si_cpu = cpu;
}
- return -1;
+ return si_cpu;
}
#else /* CONFIG_SCHED_SMT */
@@ -5931,7 +5951,7 @@ static int select_idle_cpu(struct task_struct *p, struct
sched_domain *sd, int t
u64 avg_cost, avg_idle;
u64 time, cost;
s64 delta;
- int cpu, nr = INT_MAX;
+ int cpu, nr = INT_MAX, si_cpu = -1;
int this = smp_processor_id();
this_sd = rcu_dereference(*this_cpu_ptr(_llc));
@@ -5960,11 +5980,13 @@ static int select_idle_cpu(struct task_struct *p,
struct sched_domain *sd, int t
for_each_cpu_wrap(cpu, sched_domain_span(sd), target) {
if (!--nr)
- return -1;
+ return si_cpu;
if (!cpumask_test_cpu(cpu, p->cpus_ptr))
continue;
if (available_idle_cpu(cpu))
break;
+ if (si_cpu == -1 && sched_idle_cpu(cpu))
+ si_cpu = cpu;
}
time = cpu_clock(this) - time;
@@ -5983,13 +6005,14 @@ static int select_idle_sibling(struct task_struct *p,
int prev, int target)
struct sched_domain *sd;
int i, recent_used_cpu;
- if (available_idle_cpu(target))
+ if (available_idle_cpu(target) || sched_idle_cpu(target))
return target;
/*
* If the previous CPU is cache affine and idle, don't be stupid:
*/
- if (prev
[PATCH V3 1/2] sched: Start tracking SCHED_IDLE tasks count in cfs_rq
Track how many tasks are present with SCHED_IDLE policy in each cfs_rq.
This will be used by later commits.
Signed-off-by: Viresh Kumar
---
kernel/sched/fair.c | 14 --
kernel/sched/sched.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 036be95a87e9..1277adc3e7ed 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4500,7 +4500,7 @@ static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
struct rq *rq = rq_of(cfs_rq);
struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(cfs_rq->tg);
struct sched_entity *se;
- long task_delta, dequeue = 1;
+ long task_delta, idle_task_delta, dequeue = 1;
bool empty;
se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
@@ -4511,6 +4511,7 @@ static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
rcu_read_unlock();
task_delta = cfs_rq->h_nr_running;
+ idle_task_delta = cfs_rq->idle_h_nr_running;
for_each_sched_entity(se) {
struct cfs_rq *qcfs_rq = cfs_rq_of(se);
/* throttled entity or throttle-on-deactivate */
@@ -4520,6 +4521,7 @@ static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
if (dequeue)
dequeue_entity(qcfs_rq, se, DEQUEUE_SLEEP);
qcfs_rq->h_nr_running -= task_delta;
+ qcfs_rq->idle_h_nr_running -= idle_task_delta;
if (qcfs_rq->load.weight)
dequeue = 0;
@@ -4559,7 +4561,7 @@ void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(cfs_rq->tg);
struct sched_entity *se;
int enqueue = 1;
- long task_delta;
+ long task_delta, idle_task_delta;
se = cfs_rq->tg->se[cpu_of(rq)];
@@ -4579,6 +4581,7 @@ void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
return;
task_delta = cfs_rq->h_nr_running;
+ idle_task_delta = cfs_rq->idle_h_nr_running;
for_each_sched_entity(se) {
if (se->on_rq)
enqueue = 0;
@@ -4587,6 +4590,7 @@ void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
if (enqueue)
enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP);
cfs_rq->h_nr_running += task_delta;
+ cfs_rq->idle_h_nr_running += idle_task_delta;
if (cfs_rq_throttled(cfs_rq))
break;
@@ -5200,6 +5204,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p,
int flags)
{
struct cfs_rq *cfs_rq;
struct sched_entity *se = >se;
+ int idle_h_nr_running = task_has_idle_policy(p);
/*
* The code below (indirectly) updates schedutil which looks at
@@ -5232,6 +5237,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p,
int flags)
if (cfs_rq_throttled(cfs_rq))
break;
cfs_rq->h_nr_running++;
+ cfs_rq->idle_h_nr_running += idle_h_nr_running;
flags = ENQUEUE_WAKEUP;
}
@@ -5239,6 +5245,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p,
int flags)
for_each_sched_entity(se) {
cfs_rq = cfs_rq_of(se);
cfs_rq->h_nr_running++;
+ cfs_rq->idle_h_nr_running += idle_h_nr_running;
if (cfs_rq_throttled(cfs_rq))
break;
@@ -5300,6 +5307,7 @@ static void dequeue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
struct cfs_rq *cfs_rq;
struct sched_entity *se = >se;
int task_sleep = flags & DEQUEUE_SLEEP;
+ int idle_h_nr_running = task_has_idle_policy(p);
for_each_sched_entity(se) {
cfs_rq = cfs_rq_of(se);
@@ -5314,6 +5322,7 @@ static void dequeue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
if (cfs_rq_throttled(cfs_rq))
break;
cfs_rq->h_nr_running--;
+ cfs_rq->idle_h_nr_running -= idle_h_nr_running;
/* Don't dequeue parent if it has other entities besides us */
if (cfs_rq->load.weight) {
@@ -5333,6 +5342,7 @@ static void dequeue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
for_each_sched_entity(se) {
cfs_rq = cfs_rq_of(se);
cfs_rq->h_nr_running--;
+ cfs_rq->idle_h_nr_running -= idle_h_nr_running;
if (cfs_rq_throttled(cfs_rq))
break;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 802b1f3405f2..1f95411f5e61 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -484,6 +484,8 @@ struct cfs_rq {
unsigned long runnable_weight;
unsigned intnr_running;
unsigned inth_nr_running;
+ /* h_nr_running for SCHED_IDLE tasks */
+ unsigned intidle_h_nr_running;
Re: [PATCH bpf-next] libbpf: fix max() type mismatch for 32bit
On Tue, Jun 25, 2019 at 1:28 PM Ivan Khoronzhuk
wrote:
>
> It fixes build error for 32bit caused by type mismatch
> size_t/unsigned long.
>
> Signed-off-by: Ivan Khoronzhuk
> ---
Sorry, forgot to mention, this should probably have
Fixes: bf82927125dd ("libbpf: refactor map initialization")
With that:
Acked-by: Andrii Nakryiko
> tools/lib/bpf/libbpf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 68f45a96769f..5186b7710430 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -778,7 +778,7 @@ static struct bpf_map *bpf_object__add_map(struct
> bpf_object *obj)
> if (obj->nr_maps < obj->maps_cap)
> return >maps[obj->nr_maps++];
>
> - new_cap = max(4ul, obj->maps_cap * 3 / 2);
> + new_cap = max((size_t)4, obj->maps_cap * 3 / 2);
> new_maps = realloc(obj->maps, new_cap * sizeof(*obj->maps));
> if (!new_maps) {
> pr_warning("alloc maps for object failed\n");
> --
> 2.17.1
>
[PATCH v3] x86/tls: Fix possible spectre-v1 in do_get_thread_area()
The index to access the threads tls array is controlled by userspace
via syscall: sys_ptrace(), hence leading to a potential exploitation
of the Spectre variant 1 vulnerability.
The idx can be controlled from:
ptrace -> arch_ptrace -> do_get_thread_area.
Fix this by sanitizing idx before using it to index p->thread.tls_array.
Signed-off-by: Dianzhang Chen
---
arch/x86/kernel/tls.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/tls.c b/arch/x86/kernel/tls.c
index a5b802a..71d3fef 100644
--- a/arch/x86/kernel/tls.c
+++ b/arch/x86/kernel/tls.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
@@ -220,6 +221,7 @@ int do_get_thread_area(struct task_struct *p, int idx,
struct user_desc __user *u_info)
{
struct user_desc info;
+ int index;
if (idx == -1 && get_user(idx, _info->entry_number))
return -EFAULT;
@@ -227,8 +229,11 @@ int do_get_thread_area(struct task_struct *p, int idx,
if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX)
return -EINVAL;
- fill_user_desc(, idx,
- >thread.tls_array[idx - GDT_ENTRY_TLS_MIN]);
+ index = idx - GDT_ENTRY_TLS_MIN;
+ index = array_index_nospec(index,
+ GDT_ENTRY_TLS_MAX - GDT_ENTRY_TLS_MIN + 1);
+
+ fill_user_desc(, idx, >thread.tls_array[index]);
if (copy_to_user(u_info, , sizeof(info)))
return -EFAULT;
--
2.7.4
Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't
On Tue, 25 Jun 2019, Alexandre Belloni wrote: > On 25/06/2019 11:53:49+1000, Finn Thain wrote: > > On Mon, 24 Jun 2019, Alexandre Belloni wrote: > > > > > On 21/06/2019 11:51:26+1000, Finn Thain wrote: > > > > Some machines store local time in the Real Time Clock. The > > > > hard-coded "UTC" string is wrong on those machines so just omit > > > > that string. Update the log parser so it doesn't require the > > > > string "UTC". > > > > > > > > > > I don't agree, hctossys will always think the RTC is in UTC. > > > > Well, I wasn't speculating about a theoretical problem. This is a bug > > that was reported to me by a user of Debian/powerpc system. > > > > I was able to confirm that the bug also affects dual-boot > > Windows/Linux on x86 with CONFIG_RTC_HCTOSYS=y. > > > > > If you store local time in the RTC, then you are probably not using > > > hctosys because it definitively doesn't know about the timezone and > > > will incorrectly set the system time. That information is usually > > > kept in /etc/adjtime. > > > > > > > In the Debian/powerpc bug report, the timezone is obtained from the NVRAM: > > > > [0.00] PowerMac motherboard: PowerBook Wallstreet > > ... > > [0.00] GMT Delta read from XPRAM: -360 minutes, DST: on > > ... > > [ 37.605859] rtc-generic rtc-generic: rtc core: registered rtc-generic as > > rtc0 > > ... > > [ 40.346255] rtc-generic rtc-generic: setting system clock to 2019-06-19 > > 15:17:35 UTC (1560957455) > > ... > > > > Though I don't know whether the sys_tz value is relevant here. > > > > Anyway, here's the bug reproduced on x86 -- > > > > # dmesg | grep rtc_cmos > > [0.543878] rtc_cmos 00:02: RTC can wake from S4 > > [0.544090] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 > > [0.544090] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes > > nvram, hpet irqs > > [0.545807] rtc_cmos 00:02: setting system clock to 2019-06-25 11:24:14 > > UTC (1561461854) > > # grep . /etc/adjtime /etc/timezone > > /etc/adjtime:0.000120 1550184138 0.00 > > /etc/adjtime:1550184138 > > /etc/adjtime:LOCAL > > /etc/timezone:Australia/Melbourne > > # hwclock --show > > 2019-06-25 11:47:49.702660+10:00 > > # date --iso-8601=s > > 2019-06-25T11:48:01+10:00 > > # > > > > Looks wrong to me. What am I missing? > > > > Userspace is certainly adjusting the timezone after the kernel did. Can > you run the same commands without running your init? > Sure. I booted into /bin/sh instead of /sbin/init then mounted /proc and /dev, and got this: # dmesg | grep rtc_cmos [0.544046] rtc_cmos 00:02: RTC can wake from S4 [0.544246] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 [0.544246] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs [0.545514] rtc_cmos 00:02: setting system clock to 2019-06-26 14:19:40 UTC (1561558780) # grep . /etc/adjtime /etc/timezone /etc/adjtime:0.000120 1550184138 0.00 /etc/adjtime:1550184138 /etc/adjtime:LOCAL /etc/timezone:Australia/Melbourne # hwclock --show 2019-06-26 14:22:25.437089+10:00 # date --iso-8601=s 2019-06-27T00:22:45+10:00 As expected, the kernel message still agrees with the output from hwclock. > On stable, you have /etc/init.d/hwclock.sh that still runs and does the > correct thing. My understanding is that systemd also handles the TZ > properly after hctosys (see clock_is_localtime()). > This was Gentoo/x86 with openrc. The Debian/powerpc problem is exactly the same: the kernel messages report local time whilst claiming that it's UTC. > Seriously, hctosys does a really bad job at setting the system time, it > is guaranteed to be always wrong on most platforms. My plan is still to > try to get distros to stop enabling it and do that properly in > userspace. This is already ok when using sysV but systemd would need a > few changes to stop relying on it when then is no hwclock initscript. > Unfortunately, I didn't have time to work on that yet. > It doesn't help if you are able to change all of the future distros. If you remove hctosys you will break some distros which have already shipped. For example, I've seen a Debian release that will force a fsck of the root filesystem without CONFIG_RTC_HCTOSYS. This is a temporary denial of service not a failure, but in general a backward jump by a few hours can have bad consequences, such as services that refuse to start. Anyway, this bug is about a misleading printk, it isn't about removing functionality. Why conflate these two issues? --
Re: [PATCH v2] x86/tls: Fix possible spectre-v1 in do_get_thread_area()
On Wed, Jun 26, 2019 at 12:38 AM Thomas Gleixner wrote:
>
> On Wed, 26 Jun 2019, Dianzhang Chen wrote:
>
> > The index to access the threads tls array is controlled by userspace
> > via syscall: sys_ptrace(), hence leading to a potential exploitation
> > of the Spectre variant 1 vulnerability.
> > The idx can be controlled from:
> > ptrace -> arch_ptrace -> do_get_thread_area.
> >
> > Fix this by sanitizing idx before using it to index p->thread.tls_array.
>
> Just that I can't find a place which sanitizes the value
>
> > +#include
>
> and nothing which uses anything from this header file.
>
> > #include
> > #include
> > @@ -220,6 +221,7 @@ int do_get_thread_area(struct task_struct *p, int idx,
> > struct user_desc __user *u_info)
> > {
> > struct user_desc info;
> > + int index;
> >
> > if (idx == -1 && get_user(idx, _info->entry_number))
> > return -EFAULT;
> > @@ -227,8 +229,9 @@ int do_get_thread_area(struct task_struct *p, int idx,
> > if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX)
> > return -EINVAL;
> >
> > - fill_user_desc(, idx,
> > ->thread.tls_array[idx - GDT_ENTRY_TLS_MIN]);
> > + index = idx - GDT_ENTRY_TLS_MIN;
> > +
> > + fill_user_desc(, idx, >thread.tls_array[index]);
>
> So this is just a cosmetic change and the compiler will create probably
> exactly the same binary.
>
> Thanks,
>
> tglx
>
sorry for being careless, my bad.
And thanks for suggestion, i'll fix that in next version.
Re: kernel panic: stack is corrupted in validate_chain
syzbot has bisected this bug to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend
Date: Sat Jun 30 13:17:47 2018 +
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11d4e129a0
start commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=13d4e129a0
console output: https://syzkaller.appspot.com/x/log.txt?x=15d4e129a0
kernel config: https://syzkaller.appspot.com/x/.config?x=9a31528e58cc12e2
dashboard link: https://syzkaller.appspot.com/bug?extid=6ba34346b252f2d497c7
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=135e34eea0
Reported-by: syzbot+6ba34346b252f2d49...@syzkaller.appspotmail.com
Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
linux-next: manual merge of the keys tree with the integrity tree
Hi all,
Today's linux-next merge of the keys tree got a conflict in:
security/integrity/digsig.c
between commit:
8c655784e2cf ("integrity: Fix __integrity_init_keyring() section mismatch")
from the integrity tree and commit:
79512db59dc8 ("keys: Replace uid/gid/perm permissions checking with an ACL")
from the keys tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc security/integrity/digsig.c
index 868ade3e8970,e432900c00b9..
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@@ -69,9 -70,8 +70,9 @@@ int integrity_digsig_verify(const unsig
return -EOPNOTSUPP;
}
-static int __integrity_init_keyring(const unsigned int id, struct key_acl
*acl,
- struct key_restriction *restriction)
+static int __init __integrity_init_keyring(const unsigned int id,
- key_perm_t perm,
++ struct key_acl *acl,
+ struct key_restriction *restriction)
{
const struct cred *cred = current_cred();
int err = 0;
pgprFwfnsIsSr.pgp
Description: OpenPGP digital signature
Re: [RESEND PATCH v1 0/5] Solve postboot supplier cleanup and optimize probe ordering
On Tue, Jun 25, 2019 at 11:53:13AM +0800, Greg Kroah-Hartman wrote: > On Mon, Jun 24, 2019 at 03:37:07PM -0700, Sandeep Patil wrote: > > We are trying to make sure that all (most) drivers in an Aarch64 system can > > be kernel modules for Android, like any other desktop system for > > example. There are a number of problems we need to fix before that happens > > ofcourse. > > I will argue that this is NOT an android-specific issue. If the goal of > creating an arm64 kernel that will "just work" for a wide range of > hardware configurations without rebuilding is going to happen, we need > to solve this problem with DT. This goal was one of the original wishes > of the arm64 development effort, let's not loose sight of it as > obviously, this is not working properly just yet. I believe the proposed solution in this patch series is just that. I am not sure what the alternatives are. The alternative suggested was to reuse pre-existing dt-bindings for dependency based probe re-ordering and resolution. However, it seems we had no way to *really* check if these dependencies are the real. So, a device may or may not actually depend on the other device for probe / initialization when the dependency is mentioned in it's dt node. From DT's point of view, there is no way to tell this .. I don't know how this is handled in x86. With DT, I don't see how we can do this unless DT dependencies are _really_ tied with runtime dependencies (The cycles would have been apparent if that was the case. Honestly, the "depends-on" property suggested here just piles on to the existing state. So, it is somewhat doubling the exiting bindings. It says, you must use depends-on property to define probe / initialization dependency. The existing bindings like 'clock', 'interrupt', '*-supply' do not enforce that right now, so you will have device nodes that have these bindings right now but don't necessarily need them for successful probe for example. > > It just seems that Android is the first one to actually try and > implement that goal :) I guess :) - ssp > > thanks, > > greg k-h
linux-next: manual merge of the keys tree with the ecryptfs tree
Hi all,
Today's linux-next merge of the keys tree got a conflict in:
fs/ecryptfs/keystore.c
between commit:
29a51df0609c ("ecryptfs: remove unnessesary null check in
ecryptfs_keyring_auth_tok_for_sig")
from the ecryptfs tree and commit:
79512db59dc8 ("keys: Replace uid/gid/perm permissions checking with an ACL")
from the keys tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/ecryptfs/keystore.c
index 216fbe6a4837,ba382f135918..
--- a/fs/ecryptfs/keystore.c
+++ b/fs/ecryptfs/keystore.c
@@@ -1611,10 -1610,10 +1611,10 @@@ int ecryptfs_keyring_auth_tok_for_sig(s
{
int rc = 0;
- (*auth_tok_key) = request_key(_type_user, sig, NULL);
+ (*auth_tok_key) = request_key(_type_user, sig, NULL, NULL);
- if (!(*auth_tok_key) || IS_ERR(*auth_tok_key)) {
+ if (IS_ERR(*auth_tok_key)) {
(*auth_tok_key) = ecryptfs_get_encrypted_key(sig);
- if (!(*auth_tok_key) || IS_ERR(*auth_tok_key)) {
+ if (IS_ERR(*auth_tok_key)) {
printk(KERN_ERR "Could not find key with description:
[%s]\n",
sig);
rc = process_request_key_err(PTR_ERR(*auth_tok_key));
pgpEIjwVuuleW.pgp
Description: OpenPGP digital signature
Re: Steam is broken on new kernels
On Wed, Jun 26, 2019 at 5:43 AM Guenter Roeck wrote:
>
> On 6/25/19 7:29 PM, Greg Kroah-Hartman wrote:
> > On Tue, Jun 25, 2019 at 07:02:20PM -0700, Guenter Roeck wrote:
> >> Hi Greg,
> >>
> >> On Sat, Jun 22, 2019 at 09:37:53AM +0200, Greg Kroah-Hartman wrote:
> >>> On Fri, Jun 21, 2019 at 10:28:21PM -0700, Linus Torvalds wrote:
> On Fri, Jun 21, 2019 at 6:03 PM Pierre-Loup A. Griffais
> wrote:
> >
> > I applied Eric's path to the tip of the branch and ran that kernel and
> > the bug didn't occur through several logout / login cycles, so things
> > look good at first glance. I'll keep running that kernel and report back
> > if anything crops up in the future, but I believe we're good, beyond
> > getting distros to ship this additional fix.
>
> Good. It's now in my tree, so we can get it quickly into stable and
> then quickly to distributions.
>
> Greg, it's commit b6653b3629e5 ("tcp: refine memory limit test in
> tcp_fragment()"), and I'm building it right now and I'll push it out
> in a couple of minutes assuming nothing odd is going on.
> >>>
> >>> This looks good for 4.19 and 5.1, so I'll push out new stable kernels in
> >>> a bit for them.
> >>>
> >>> But for 4.14 and older, we don't have the "hint" to know this is an
> >>> outbound going packet and not to apply these checks at that point in
> >>> time, so this patch doesn't work.
> >>>
> >>> I'll see if I can figure anything else later this afternoon for those
> >>> kernels...
> >>>
> >>
> >> I may have missed it, but I don't see a fix for the problem in
> >> older stable branches. Any news ?
> >>
> >> One possibility might be be to apply the part of 75c119afe14f7 which
> >> introduces TCP_FRAG_IN_WRITE_QUEUE and TCP_FRAG_IN_RTX_QUEUE, if that
> >> is acceptable.
> >
> > That's what people have already discussed on the stable mailing list a
> > few hours ago, hopefully a patch shows up soon as I'm traveling at the
> > moment and can't do it myself...
> >
>
> Sounds good. Let me know if nothing shows up; I'll be happy to do it
> if needed.
Without the rb-tree for rtx queues, old kernels are vulnerable to SACK
attacks if sk_sndbuf is too big,
so I would simply add a cushion in the test, instead of trying to
backport an illusion of the rb-tree fixes.
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index
a8772e11dc1cb42d4319b6fc072c625d284c7ad5..a554213afa4ac41120d781fe64b7cd18ff9b56e8
100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1274,7 +1274,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff
*skb, u32 len,
if (nsize < 0)
nsize = 0;
- if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf)) {
+ if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf + 131072)) {
NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
return -ENOMEM;
}
[PATCH] arm64/efi: Mark __efistub_stext_offset as an absolute symbol explicitly
After r363059 and r363928 in LLVM, a build using ld.lld as the linker with CONFIG_RANDOMIZE_BASE enabled fails like so: ld.lld: error: relocation R_AARCH64_ABS32 cannot be used against symbol __efistub_stext_offset; recompile with -fPIC Fangrui and Peter figured out that ld.lld is incorrectly considering __efistub_stext_offset as a relative symbol because of the order in which symbols are evaluated. _text is treated as an absolute symbol and stext is a relative symbol, making __efistub_stext_offset a relative symbol. Adding ABSOLUTE will force ld.lld to evalute this expression in the right context and does not change ld.bfd's behavior. ld.lld will need to be fixed but the developers do not see a quick or simple fix without some research (see the linked issue for further explanation). Add this simple workaround so that ld.lld can continue to link kernels. Link: https://github.com/ClangBuiltLinux/linux/issues/561 Link: https://github.com/llvm/llvm-project/commit/025a815d75d2356f2944136269aa5874721ec236 Link: https://github.com/llvm/llvm-project/commit/249fde85832c33f8b06c6b4ac65d1c4b96d23b83 Debugged-by: Fangrui Song Debugged-by: Peter Smith Suggested-by: Fangrui Song Signed-off-by: Nathan Chancellor --- arch/arm64/kernel/image.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h index 04ca08086d35..9a2d2227907c 100644 --- a/arch/arm64/kernel/image.h +++ b/arch/arm64/kernel/image.h @@ -67,7 +67,7 @@ #ifdef CONFIG_EFI -__efistub_stext_offset = stext - _text; +__efistub_stext_offset = ABSOLUTE(stext - _text); /* * The EFI stub has its own symbol namespace prefixed by __efistub_, to -- 2.22.0
[PATCH 0/2] Unexport __clk_of_table
I found this lying around, not sure if I sent it or not. We don't need to export this symbol anymore. And having COMMON_CLK in clk-provider.h seems to be an artifact. Here's a couple patches to clean this stuff up. Stephen Boyd (2): clk: Remove ifdef for COMMON_CLK in clk-provider.h clk: Unexport __clk_of_table drivers/clk/clk.c| 1 + include/linux/clk-provider.h | 7 --- 2 files changed, 1 insertion(+), 7 deletions(-) -- Sent by a computer through tubes
[PATCH 2/2] clk: Unexport __clk_of_table
This symbol doesn't need to be exported to clk providers anymore.
Originally, it was hidden inside clk.c, but then OMAP needed to get
access to it in commit 819b4861c18d ("CLK: ti: add init support for
clock IP blocks"), but eventually that code also changed in commit
c08ee14cc663 ("clk: ti: change clock init to use generic of_clk_init")
and we were left with this exported. Move this back into clk.c so that
it isn't exposed anymore.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c| 1 +
include/linux/clk-provider.h | 4
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index aa51756fd4d6..b34e84bb8167 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -4038,6 +4038,7 @@ struct of_clk_provider {
void *data;
};
+extern struct of_device_id __clk_of_table;
static const struct of_device_id __clk_of_table_sentinel
__used __section(__clk_of_table_end);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 3bced2ec9f26..9ba000e3a50d 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -865,8 +865,6 @@ static inline long divider_ro_round_rate(struct clk_hw *hw,
unsigned long rate,
*/
unsigned long clk_hw_round_rate(struct clk_hw *hw, unsigned long rate);
-struct of_device_id;
-
struct clk_onecell_data {
struct clk **clks;
unsigned int clk_num;
@@ -877,8 +875,6 @@ struct clk_hw_onecell_data {
struct clk_hw *hws[];
};
-extern struct of_device_id __clk_of_table;
-
#define CLK_OF_DECLARE(name, compat, fn) OF_DECLARE_1(clk, name, compat, fn)
/*
--
Sent by a computer through tubes
[PATCH 1/2] clk: Remove ifdef for COMMON_CLK in clk-provider.h
This ifdef has been there since the beginning of this file, but it doesn't really seem to serve any purpose besides obfuscating the struct definitions and #defines here from compilation units that include it. Let's always expose these function prototypes and struct definitions so that code can inspect clk providers without needing to have CONFIG_COMMON_CLK enabled. Signed-off-by: Stephen Boyd --- include/linux/clk-provider.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index bb6118f79784..3bced2ec9f26 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -9,8 +9,6 @@ #include #include -#ifdef CONFIG_COMMON_CLK - /* * flags used across common struct clk. these flags should only affect the * top-level framework. custom flags for dealing with hardware specifics @@ -1019,5 +1017,4 @@ static inline int of_clk_detect_critical(struct device_node *np, int index, void clk_gate_restore_context(struct clk_hw *hw); -#endif /* CONFIG_COMMON_CLK */ #endif /* CLK_PROVIDER_H */ -- Sent by a computer through tubes
Re: [PATCH 8/9] x86/tlb: Privatize cpu_tlbstate
On Tue, Jun 25, 2019 at 2:52 PM Dave Hansen wrote: > > On 6/12/19 11:48 PM, Nadav Amit wrote: > > cpu_tlbstate is mostly private and only the variable is_lazy is shared. > > This causes some false-sharing when TLB flushes are performed. > > Presumably, all CPUs doing TLB flushes read 'is_lazy'. Because of this, > when we write to it we have to do the cache coherency dance to get rid > of all the CPUs that might have a read-only copy. > > I would have *thought* that we only do writes when we enter or exist > lazy mode. That's partially true. We do write in enter_lazy_tlb(), but > we also *unconditionally* write in switch_mm_irqs_off(). That seems > like it might be responsible for a chunk (or even a vast majority) of > the cacheline bounces. > > Is there anything preventing us from turning the switch_mm_irqs_off() > write into: > > if (was_lazy) > this_cpu_write(cpu_tlbstate.is_lazy, false); > > ? > > I think this patch is probably still a good general idea, but I just > wonder if reducing the writes is a better way to reduce bounces. Good catch! I'm usually pretty good about this for test_and_set()-style things, but I totally missed this obvious unnecessary write when I did this. I hereby apologize for all the cycles I wasted :) --Andy
Re: [PATCH] linux/kernel.h: fix overflow for DIV_ROUND_UP_ULL
On 25-06-19, 15:32, Andrew Morton wrote:
> On Tue, 25 Jun 2019 15:29:38 -0700 Andrew Morton
> wrote:
>
> > On Tue, 25 Jun 2019 15:35:18 +0530 Vinod Koul wrote:
> >
> > > DIV_ROUND_UP_ULL adds the two arguments and then invokes
> > > DIV_ROUND_DOWN_ULL. But on a 32bit system the addition of two 32 bit
> > > values can overflow. DIV_ROUND_DOWN_ULL does it correctly and stashes
> > > the addition into a unsigned long long so cast the result to unsigned
> > > long long here to avoid the overflow condition.
> > >
> > > ...
> > >
> > > --- a/include/linux/kernel.h
> > > +++ b/include/linux/kernel.h
> > > @@ -93,7 +93,8 @@
> > > #define DIV_ROUND_DOWN_ULL(ll, d) \
> > > ({ unsigned long long _tmp = (ll); do_div(_tmp, d); _tmp; })
> > >
> > > -#define DIV_ROUND_UP_ULL(ll, d) DIV_ROUND_DOWN_ULL((ll) + (d) -
> > > 1, (d))
> > > +#define DIV_ROUND_UP_ULL(ll, d) \
> > > + ({ DIV_ROUND_DOWN_ULL((unsigned long long)(ll) + (d) - 1, (d)) })
> > >
> >
> > This clearly wasn't tested :(
Apologies for that, I did test and stash, but failed to amend the
commit. I should have noticed while sending but :(
Anyway I had the same conclusion as yous, so all is good.
Thanks for fixing this
Reviewed-by: Vinod Koul
Tested-by: Vinod Koul
> >
> > fs/fs-writeback.c: In function wb_split_bdi_pages:
> > ./include/linux/kernel.h:97:65: error: expected ; before } token
> > ({ DIV_ROUND_DOWN_ULL((unsigned long long)(ll) + (d) - 1, (d)) })
> > ^
> > fs/fs-writeback.c:811:10: note: in expansion of macro DIV_ROUND_UP_ULL
> >return DIV_ROUND_UP_ULL((u64)nr_pages * this_bw, tot_bw);
> >
> >
> > From: Andrew Morton
> > Subject: linux-kernelh-fix-overflow-for-div_round_up_ull-fix
> >
> > DIV_ROUND_UP_ULL must be an rval
> >
> > Cc: Bjorn Andersson
> > Cc: Randy Dunlap
> > Cc: Vinod Koul
> > Signed-off-by: Andrew Morton
> > ---
> >
> > include/linux/kernel.h |6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > ---
> > a/include/linux/kernel.h~linux-kernelh-fix-overflow-for-div_round_up_ull-fix
> > +++ a/include/linux/kernel.h
> > @@ -93,8 +93,10 @@
> > #define DIV_ROUND_DOWN_ULL(ll, d) \
> > ({ unsigned long long _tmp = (ll); do_div(_tmp, d); _tmp; })
> >
> > -#define DIV_ROUND_UP_ULL(ll, d) \
> > - ({ DIV_ROUND_DOWN_ULL((unsigned long long)(ll) + (d) - 1, (d)) })
> > +#define DIV_ROUND_UP_ULL(ll, d) ({ \
> > + unsigned long long _tmp; \
> > + _tmp = DIV_ROUND_DOWN_ULL((unsigned long long)(ll) + (d) - 1, (d)); \
> > + _tmp; })
>
> Simpler:
>
> ---
> a/include/linux/kernel.h~linux-kernelh-fix-overflow-for-div_round_up_ull-fix
> +++ a/include/linux/kernel.h
> @@ -94,7 +94,7 @@
> ({ unsigned long long _tmp = (ll); do_div(_tmp, d); _tmp; })
>
> #define DIV_ROUND_UP_ULL(ll, d) \
> - ({ DIV_ROUND_DOWN_ULL((unsigned long long)(ll) + (d) - 1, (d)) })
> + DIV_ROUND_DOWN_ULL((unsigned long long)(ll) + (d) - 1, (d))
>
> #if BITS_PER_LONG == 32
> # define DIV_ROUND_UP_SECTOR_T(ll,d) DIV_ROUND_UP_ULL(ll, d)
> _
--
~Vinod
Re: [PATCH 6/9] KVM: x86: Provide paravirtualized flush_tlb_multi()
On Tue, Jun 25, 2019 at 8:41 PM Nadav Amit wrote:
>
> > On Jun 25, 2019, at 8:35 PM, Andy Lutomirski wrote:
> >
> > On Tue, Jun 25, 2019 at 7:39 PM Nadav Amit wrote:
> >>> On Jun 25, 2019, at 2:40 PM, Dave Hansen wrote:
> >>>
> >>> On 6/12/19 11:48 PM, Nadav Amit wrote:
> Support the new interface of flush_tlb_multi, which also flushes the
> local CPU's TLB, instead of flush_tlb_others that does not. This
> interface is more performant since it parallelize remote and local TLB
> flushes.
>
> The actual implementation of flush_tlb_multi() is almost identical to
> that of flush_tlb_others().
> >>>
> >>> This confused me a bit. I thought we didn't support paravirtualized
> >>> flush_tlb_multi() from reading earlier in the series.
> >>>
> >>> But, it seems like that might be Xen-only and doesn't apply to KVM and
> >>> paravirtualized KVM has no problem supporting flush_tlb_multi(). Is
> >>> that right? It might be good to include some of that background in the
> >>> changelog to set the context.
> >>
> >> I’ll try to improve the change-logs a bit. There is no inherent reason for
> >> PV TLB-flushers not to implement their own flush_tlb_multi(). It is left
> >> for future work, and here are some reasons:
> >>
> >> 1. Hyper-V/Xen TLB-flushing code is not very simple
> >> 2. I don’t have a proper setup
> >> 3. I am lazy
> >
> > In the long run, I think that we're going to want a way for one CPU to
> > do a remote flush and then, with appropriate locking, update the
> > tlb_gen fields for the remote CPU. Getting this right may be a bit
> > nontrivial.
>
> What do you mean by “do a remote flush”?
>
I mean a PV-assisted flush on a CPU other than the CPU that started
it. If you look at flush_tlb_func_common(), it's doing some work that
is rather fancier than just flushing the TLB. By replacing it with
just a pure flush on Xen or Hyper-V, we're losing the potential CR3
switch and this bit:
/* Both paths above update our state to mm_tlb_gen. */
this_cpu_write(cpu_tlbstate.ctxs[loaded_mm_asid].tlb_gen, mm_tlb_gen);
Skipping the former can hurt idle performance, although we should
consider just disabling all the lazy optimizations on systems with PV
flush. (And I've asked Intel to help us out here in future hardware.
I have no idea what the result of asking will be.) Skipping the
cpu_tlbstate write means that we will do unnecessary flushes in the
future, and that's not doing us any favors.
In principle, we should be able to do something like:
flush_tlb_multi(...);
for(each CPU that got flushed) {
spin_lock(something appropriate?);
per_cpu_write(cpu, cpu_tlbstate.ctxs[loaded_mm_asid].tlb_gen, f->new_tlb_gen);
spin_unlock(...);
}
with the caveat that it's more complicated than this if the flush is a
partial flush, and that we'll want to check that the ctx_id still
matches, etc.
Does this make sense?
[PATCH v2] pinctrl: mediatek: Update cur_mask in mask/mask ops
During suspend/resume, mtk_eint_mask may be called while
wake_mask is active. For example, this happens if a wake-source
with an active interrupt handler wakes the system:
irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so
that it can be handled later on in the resume flow.
However, this may happen before mtk_eint_do_resume is called:
in this case, wake_mask is loaded, and cur_mask is restored
from an older copy, re-enabling the interrupt, and causing
an interrupt storm (especially for level interrupts).
Step by step, for a line that has both wake and interrupt enabled:
1. cur_mask[irq] = 1; wake_mask[irq] = 1; EINT_EN[irq] = 1 (interrupt
enabled at hardware level)
2. System suspends, resumes due to that line (at this stage EINT_EN
== wake_mask)
3. irq_pm_check_wakeup is called, and disables the interrupt =>
EINT_EN[irq] = 0, but we still have cur_mask[irq] = 1
4. mtk_eint_do_resume is called, and restores EINT_EN = cur_mask, so
it reenables EINT_EN[irq] = 1 => interrupt storm as the driver
is not yet ready to handle the interrupt.
This patch fixes the issue in step 3, by recording all mask/unmask
changes in cur_mask. This also avoids the need to read the current
mask in eint_do_suspend, and we can remove mtk_eint_chip_read_mask
function.
The interrupt will be re-enabled properly later on, sometimes after
mtk_eint_do_resume, when the driver is ready to handle it.
Fixes: 58a5e1b64b ("pinctrl: mediatek: Implement wake handler and suspend
resume")
Signed-off-by: Nicolas Boichat
Acked-by: Sean Wang
---
Applies on top of linux-pinctrl.git/fixes.
Changes from v2:
- Added Fixes tag
- Reworded the commit message, added an example. Sean: I hope
that's what you had in mind, I can reword further, if needed.
Note that IRQCHIP_MASK_ON_SUSPEND does not work here, as it does
not handle lines that are enabled as a wake source, but without
interrupt enabled (e.g. cros_ec driver does that), which we do want
to support.
Also, Stephen Boyd suggested refactoring the genirq layer to make
it aware of such IRQ controllers. I may try to look at this in the
future, but don't have the cycles right now ,-(
drivers/pinctrl/mediatek/mtk-eint.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/pinctrl/mediatek/mtk-eint.c
b/drivers/pinctrl/mediatek/mtk-eint.c
index 737385e86beb807..7e526bcf5e0b55c 100644
--- a/drivers/pinctrl/mediatek/mtk-eint.c
+++ b/drivers/pinctrl/mediatek/mtk-eint.c
@@ -113,6 +113,8 @@ static void mtk_eint_mask(struct irq_data *d)
void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq,
eint->regs->mask_set);
+ eint->cur_mask[d->hwirq >> 5] &= ~mask;
+
writel(mask, reg);
}
@@ -123,6 +125,8 @@ static void mtk_eint_unmask(struct irq_data *d)
void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq,
eint->regs->mask_clr);
+ eint->cur_mask[d->hwirq >> 5] |= mask;
+
writel(mask, reg);
if (eint->dual_edge[d->hwirq])
@@ -217,19 +221,6 @@ static void mtk_eint_chip_write_mask(const struct mtk_eint
*eint,
}
}
-static void mtk_eint_chip_read_mask(const struct mtk_eint *eint,
- void __iomem *base, u32 *buf)
-{
- int port;
- void __iomem *reg;
-
- for (port = 0; port < eint->hw->ports; port++) {
- reg = base + eint->regs->mask + (port << 2);
- buf[port] = ~readl_relaxed(reg);
- /* Mask is 0 when irq is enabled, and 1 when disabled. */
- }
-}
-
static int mtk_eint_irq_request_resources(struct irq_data *d)
{
struct mtk_eint *eint = irq_data_get_irq_chip_data(d);
@@ -384,7 +375,6 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
int mtk_eint_do_suspend(struct mtk_eint *eint)
{
- mtk_eint_chip_read_mask(eint, eint->base, eint->cur_mask);
mtk_eint_chip_write_mask(eint, eint->base, eint->wake_mask);
return 0;
--
2.22.0.410.gd8fdbe21b5-goog
Re: [RFC v1] clk: core: support clocks that need to be enabled during re-parent
Quoting Weiyi Lu (2019-06-25 18:05:22) > On Tue, 2019-06-25 at 15:14 -0700, Stephen Boyd wrote: > > Quoting Weiyi Lu (2019-06-09 20:44:53) > > > When using property assigned-clock-parents to assign parent clocks, > > > core clocks might still be disabled during re-parent. > > > Add flag 'CLK_OPS_CORE_ENABLE' for those clocks must be enabled > > > during re-parent. > > > > > > Signed-off-by: Weiyi Lu > > > > Can you further describe the scenario where this is a problem? Is it > > some sort of clk that is enabled by default out of the bootloader and is > > then configured to have an 'assigned-clock-parents' property to change > > the parent, but that clk needs to be "enabled" so that the framework > > turns on the parents for the parent switch? > > When driver is built as module(.ko) and install at runtime after the > whole initialization stage. Clk might already be turned off before > configuring by assigned-clock-parents. For such clock design that need > to have clock enabled during re-parent, the configuration of > assigned-clock-parents might be failed. That's the problem we have now. Great. Please put this sort of information in the commit text. > Do you have any suggestion for such usage of clocks? Many thanks. > Ok, and in this case somehow CLK_OPS_PARENT_ENABLE flag doesn't work? Is that because the clk itself doesn't do anything unless it's enabled? I seem to recall that we usually work around this by caching the state of the clk parents or frequencies and then when the clk prepare or enable op is called we actually write the hardware to change the state. There are some qcom clks like this and we basically just use the hardware itself to cache the state of the clk while it hasn't actually changed to be at that rate, because the clk is not enabled yet. The main concern is that we're having to turn on clks to make things work, when it would be best to not turn on clks just so that register writes actually make a difference to what the hardware does.
[PATCH AUTOSEL 5.1 11/51] ASoC: sun4i-codec: fix first delay on Speaker
From: Georgii Staroselskii
[ Upstream commit 1f2675f6655838aaf910f911fd0abc821e3ff3df ]
Allwinner DAC seems to have a delay in the Speaker audio routing. When
playing a sound for the first time, the sound gets chopped. On a second
play the sound is played correctly. After some time (~5s) the issue gets
back.
This commit seems to be fixing the same issue as bf14da7 but
for another codepath.
This is the DTS that was used to debug the problem.
{
allwinner,pa-gpios = <_pio 0 11 GPIO_ACTIVE_HIGH>; /* PL11 */
allwinner,audio-routing =
"Speaker", "LINEOUT";
status = "okay";
}
Signed-off-by: Georgii Staroselskii
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/sunxi/sun4i-codec.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 15d08e343b47..28d2f7713f8d 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1329,6 +1329,15 @@ static int sun4i_codec_spk_event(struct
snd_soc_dapm_widget *w,
gpiod_set_value_cansleep(scodec->gpio_pa,
!!SND_SOC_DAPM_EVENT_ON(event));
+ if (SND_SOC_DAPM_EVENT_ON(event)) {
+ /*
+* Need a delay to wait for DAC to push the data. 700ms seems
+* to be the best compromise not to feel this delay while
+* playing a sound.
+*/
+ msleep(700);
+ }
+
return 0;
}
--
2.20.1
[PATCH AUTOSEL 5.1 23/51] x86/CPU: Add more Icelake model numbers
From: Kan Liang [ Upstream commit e35faeb64146f2015f2aec14b358ae508e4066db ] Add the CPUID model numbers of Icelake (ICL) desktop and server processors to the Intel family list. [ Qiuxu: Sort the macros by model number. ] Signed-off-by: Kan Liang Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Andy Shevchenko Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Qiuxu Zhuo Cc: Rajneesh Bhardwaj Cc: rui.zh...@intel.com Cc: Thomas Gleixner Cc: Tony Luck Cc: x86-ml Link: https://lkml.kernel.org/r/20190603134122.13853-1-kan.li...@linux.intel.com Signed-off-by: Sasha Levin --- arch/x86/include/asm/intel-family.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index 9f15384c504a..310118805f57 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -52,6 +52,9 @@ #define INTEL_FAM6_CANNONLAKE_MOBILE 0x66 +#define INTEL_FAM6_ICELAKE_X 0x6A +#define INTEL_FAM6_ICELAKE_XEON_D 0x6C +#define INTEL_FAM6_ICELAKE_DESKTOP 0x7D #define INTEL_FAM6_ICELAKE_MOBILE 0x7E /* "Small Core" Processors (Atom) */ -- 2.20.1
[PATCH AUTOSEL 5.1 06/51] spi: bitbang: Fix NULL pointer dereference in spi_unregister_master
From: YueHaibing
[ Upstream commit 5caaf29af5ca82d5da8bc1d0ad07d9e664ccf1d8 ]
If spi_register_master fails in spi_bitbang_start
because device_add failure, We should return the
error code other than 0, otherwise calling
spi_bitbang_stop may trigger NULL pointer dereference
like this:
BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0
Read of size 8 at addr by task syz-executor.0/3661
CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
04/01/2014
Call Trace:
dump_stack+0xa9/0x10e
? __list_del_entry_valid+0x45/0xd0
? __list_del_entry_valid+0x45/0xd0
__kasan_report+0x171/0x18d
? __list_del_entry_valid+0x45/0xd0
kasan_report+0xe/0x20
__list_del_entry_valid+0x45/0xd0
spi_unregister_controller+0x99/0x1b0
spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp]
? 0xc1128000
? klist_next+0x131/0x1e0
? driver_detach+0x40/0x40 [parport]
port_check+0x3b/0x50 [parport]
bus_for_each_dev+0x115/0x180
? subsys_dev_iter_exit+0x20/0x20
__parport_register_driver+0x1f0/0x210 [parport]
? 0xc115
do_one_initcall+0xb9/0x3b5
? perf_trace_initcall_level+0x270/0x270
? kasan_unpoison_shadow+0x30/0x40
? kasan_unpoison_shadow+0x30/0x40
do_init_module+0xe0/0x330
load_module+0x38eb/0x4270
? module_frob_arch_sections+0x20/0x20
? kernel_read_file+0x188/0x3f0
? find_held_lock+0x6d/0xd0
? fput_many+0x1a/0xe0
? __do_sys_finit_module+0x162/0x190
__do_sys_finit_module+0x162/0x190
? __ia32_sys_init_module+0x40/0x40
? __mutex_unlock_slowpath+0xb4/0x3f0
? wait_for_completion+0x240/0x240
? vfs_write+0x160/0x2a0
? lockdep_hardirqs_off+0xb5/0x100
? mark_held_locks+0x1a/0x90
? do_syscall_64+0x14/0x2a0
do_syscall_64+0x72/0x2a0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Reported-by: Hulk Robot
Fixes: 702a4879ec33 ("spi: bitbang: Let spi_bitbang_start() take a reference to
master")
Signed-off-by: YueHaibing
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Axel Lin
Reviewed-by: Mukesh Ojha
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi-bitbang.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-bitbang.c b/drivers/spi/spi-bitbang.c
index dd9a8c54a693..be95be4fe985 100644
--- a/drivers/spi/spi-bitbang.c
+++ b/drivers/spi/spi-bitbang.c
@@ -403,7 +403,7 @@ int spi_bitbang_start(struct spi_bitbang *bitbang)
if (ret)
spi_master_put(master);
- return 0;
+ return ret;
}
EXPORT_SYMBOL_GPL(spi_bitbang_start);
--
2.20.1
[PATCH AUTOSEL 5.1 10/51] iommu/vt-d: Set the right field for Page Walk Snoop
From: Lu Baolu
[ Upstream commit 66d78ad316b0e1ca5ae19663468554e2c0e31c26 ]
Set the page walk snoop to the right bit, otherwise the domain
id field will be overlapped.
Reported-by: Dave Jiang
Fixes: 6f7db75e1c469 ("iommu/vt-d: Add second level page table interface")
Signed-off-by: Lu Baolu
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-pasid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-pasid.c b/drivers/iommu/intel-pasid.c
index 03b12d2ee213..fdf05c45d516 100644
--- a/drivers/iommu/intel-pasid.c
+++ b/drivers/iommu/intel-pasid.c
@@ -387,7 +387,7 @@ static inline void pasid_set_present(struct pasid_entry *pe)
*/
static inline void pasid_set_page_snoop(struct pasid_entry *pe, bool value)
{
- pasid_set_bits(>val[1], 1 << 23, value);
+ pasid_set_bits(>val[1], 1 << 23, value << 23);
}
/*
--
2.20.1
Re: [PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
On Tue, Jun 25, 2019 at 8:48 PM Nadav Amit wrote: > > > On Jun 25, 2019, at 8:36 PM, Andy Lutomirski wrote: > > > > On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit wrote: > >> To improve TLB shootdown performance, flush the remote and local TLBs > >> concurrently. Introduce flush_tlb_multi() that does so. The current > >> flush_tlb_others() interface is kept, since paravirtual interfaces need > >> to be adapted first before it can be removed. This is left for future > >> work. In such PV environments, TLB flushes are not performed, at this > >> time, concurrently. > > > > Would it be straightforward to have a default PV flush_tlb_multi() > > that uses flush_tlb_others() under the hood? > > I prefer not to have a default PV implementation that should anyhow go away. > > I can create unoptimized untested versions for Xen and Hyper-V, if you want. > I think I prefer that approach. We should be able to get the maintainers to test it. I don't love having legacy paths in there, ahem, UV.
[PATCH AUTOSEL 5.1 37/51] drm: panel-orientation-quirks: Add quirk for GPD MicroPC
From: Hans de Goede
[ Upstream commit 652b8b086538c8a10de5aa5cbdaef79333b46358 ]
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_micropc data struct may very well need to be updated
with some extra bios-dates in the future.
Acked-by: Maxime Ripard
Signed-off-by: Hans de Goede
Link:
https://patchwork.freedesktop.org/patch/msgid/20190524125759.14131-2-hdego...@redhat.com
(cherry picked from commit f2f2bb60d998abde10de7e483ef9e17639892450)
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 019f148d5a78..dd982563304d 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -42,6 +42,14 @@ static const struct drm_dmi_panel_orientation_data
asus_t100ha = {
.orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
};
+static const struct drm_dmi_panel_orientation_data gpd_micropc = {
+ .width = 720,
+ .height = 1280,
+ .bios_dates = (const char * const []){ "04/26/2019",
+ NULL },
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
static const struct drm_dmi_panel_orientation_data gpd_pocket = {
.width = 1200,
.height = 1920,
@@ -101,6 +109,14 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
},
.driver_data = (void *)_t100ha,
+ }, {/* GPD MicroPC (generic strings, also match on bios date) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
+ },
+ .driver_data = (void *)_micropc,
}, {/*
* GPD Pocket, note that the the DMI data is less generic then
* it seems, devices with a board-vendor of "AMI Corporation"
--
2.20.1
[PATCH AUTOSEL 5.1 25/51] usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC
From: Alexandre Belloni [ Upstream commit fbc318afadd6e7ae2252d6158cf7d0c5a2132f7d ] Gadget drivers may queue request in interrupt context. This would lead to a descriptor allocation in that context. In that case we would hit BUG_ON(in_interrupt()) in __get_vm_area_node. Also remove the unnecessary cast. Acked-by: Sylvain Lemieux Tested-by: James Grant Signed-off-by: Alexandre Belloni Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin --- drivers/usb/gadget/udc/lpc32xx_udc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c b/drivers/usb/gadget/udc/lpc32xx_udc.c index b0781771704e..eafc2a00c96a 100644 --- a/drivers/usb/gadget/udc/lpc32xx_udc.c +++ b/drivers/usb/gadget/udc/lpc32xx_udc.c @@ -922,8 +922,7 @@ static struct lpc32xx_usbd_dd_gad *udc_dd_alloc(struct lpc32xx_udc *udc) dma_addr_t dma; struct lpc32xx_usbd_dd_gad *dd; - dd = (struct lpc32xx_usbd_dd_gad *) dma_pool_alloc( - udc->dd_cache, (GFP_KERNEL | GFP_DMA), ); + dd = dma_pool_alloc(udc->dd_cache, GFP_ATOMIC | GFP_DMA, ); if (dd) dd->this_dma = dma; -- 2.20.1
[PATCH AUTOSEL 5.1 42/51] platform/x86: mlx-platform: Fix parent device in i2c-mux-reg device registration
From: Vadim Pasternak
[ Upstream commit 160da20b254dd4bfc5828f12c208fa831ad4be6c ]
Fix the issue found while running kernel with the option
CONFIG_DEBUG_TEST_DRIVER_REMOVE.
Driver 'mlx-platform' registers 'i2c_mlxcpld' device and then registers
few underlying 'i2c-mux-reg' devices:
priv->pdev_i2c = platform_device_register_simple("i2c_mlxcpld", nr,
NULL, 0);
...
for (i = 0; i < ARRAY_SIZE(mlxplat_mux_data); i++) {
priv->pdev_mux[i] = platform_device_register_resndata(
_dev->dev,
"i2c-mux-reg", i, NULL,
0, _mux_data[i],
sizeof(mlxplat_mux_data[i]));
But actual parent of "i2c-mux-reg" device is priv->pdev_i2c->dev and
not mlxplat_dev->dev.
Patch fixes parent device parameter in a call to
platform_device_register_resndata() for "i2c-mux-reg".
It solves the race during initialization flow while 'i2c_mlxcpld.1' is
removing after probe, while 'i2c-mux-reg.0' is still in probing flow:
'i2c_mlxcpld.1' flow: probe -> remove -> probe.
'i2c-mux-reg.0' flow: probe -> ...
[ 12:621096] Registering platform device 'i2c_mlxcpld.1'. Parent at platform
[ 12:621117] device: 'i2c_mlxcpld.1': device_add
[ 12:621155] bus: 'platform': add device i2c_mlxcpld.1
[ 12:621384] Registering platform device 'i2c-mux-reg.0'. Parent at mlxplat
[ 12:621395] device: 'i2c-mux-reg.0': device_add
[ 12:621425] bus: 'platform': add device i2c-mux-reg.0
[ 12:621806] Registering platform device 'i2c-mux-reg.1'. Parent at mlxplat
[ 12:621828] device: 'i2c-mux-reg.1': device_add
[ 12:621892] bus: 'platform': add device i2c-mux-reg.1
[ 12:621906] bus: 'platform': add driver i2c_mlxcpld
[ 12:621996] bus: 'platform': driver_probe_device: matched device
i2c_mlxcpld.1 with driver i2c_mlxcpld
[ 12:622003] bus: 'platform': really_probe: probing driver i2c_mlxcpld with
device i2c_mlxcpld.1
[ 12:622100] i2c_mlxcpld i2c_mlxcpld.1: no default pinctrl state
[ 12:622293] device: 'i2c-1': device_add
[ 12:627280] bus: 'i2c': add device i2c-1
[ 12:627692] device: 'i2c-1': device_add
[ 12.629639] bus: 'platform': add driver i2c-mux-reg
[ 12.629718] bus: 'platform': driver_probe_device: matched device
i2c-mux-reg.0 with driver i2c-mux-reg
[ 12.629723] bus: 'platform': really_probe: probing driver i2c-mux-reg with
device i2c-mux-reg.0
[ 12.629818] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
[ 12.629981] platform i2c-mux-reg.0: Driver i2c-mux-reg requests probe
deferral
[ 12.629986] platform i2c-mux-reg.0: Added to deferred list
[ 12.629992] bus: 'platform': driver_probe_device: matched device
i2c-mux-reg.1 with driver i2c-mux-reg
[ 12.629997] bus: 'platform': really_probe: probing driver i2c-mux-reg with
device i2c-mux-reg.1
[ 12.630091] i2c-mux-reg i2c-mux-reg.1: no default pinctrl state
[ 12.630247] platform i2c-mux-reg.1: Driver i2c-mux-reg requests probe
deferral
[ 12.630252] platform i2c-mux-reg.1: Added to deferred list
[ 12.640892] devices_kset: Moving i2c-mux-reg.0 to end of list
[ 12.640900] platform i2c-mux-reg.0: Retrying from deferred list
[ 12.640911] bus: 'platform': driver_probe_device: matched device
i2c-mux-reg.0 with driver i2c-mux-reg
[ 12.640919] bus: 'platform': really_probe: probing driver i2c-mux-reg with
device i2c-mux-reg.0
[ 12.640999] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
[ 12.641177] platform i2c-mux-reg.0: Driver i2c-mux-reg requests probe
deferral
[ 12.641187] platform i2c-mux-reg.0: Added to deferred list
[ 12.641198] devices_kset: Moving i2c-mux-reg.1 to end of list
[ 12.641219] platform i2c-mux-reg.1: Retrying from deferred list
[ 12.641237] bus: 'platform': driver_probe_device: matched device
i2c-mux-reg.1 with driver i2c-mux-reg
[ 12.641247] bus: 'platform': really_probe: probing driver i2c-mux-reg with
device i2c-mux-reg.1
[ 12.641331] i2c-mux-reg i2c-mux-reg.1: no default pinctrl state
[ 12.641465] platform i2c-mux-reg.1: Driver i2c-mux-reg requests probe
deferral
[ 12.641469] platform i2c-mux-reg.1: Added to deferred list
[ 12.646427] device: 'i2c-1': device_add
[ 12.646647] bus: 'i2c': add device i2c-1
[ 12.647104] device: 'i2c-1': device_add
[ 12.669231] devices_kset: Moving i2c-mux-reg.0 to end of list
[ 12.669240] platform i2c-mux-reg.0: Retrying from deferred list
[ 12.669258] bus: 'platform': driver_probe_device: matched device
i2c-mux-reg.0 with driver i2c-mux-reg
[ 12.669263] bus: 'platform': really_probe: probing driver i2c-mux-reg with
device i2c-mux-reg.0
[ 12.669343] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
[ 12.669585] device: 'i2c-2': device_add
[ 12.669795] bus: 'i2c': add device i2c-2
[ 12.670201] device: 'i2c-2': device_add
[ 12.671427] i2c i2c-1: Added
[PATCH AUTOSEL 5.1 47/51] scripts/decode_stacktrace.sh: prefix addr2line with $CROSS_COMPILE
From: Manuel Traut
[ Upstream commit c04e32e911653442fc834be6e92e072aeebe01a1 ]
At least for ARM64 kernels compiled with the crosstoolchain from
Debian/stretch or with the toolchain from kernel.org the line number is
not decoded correctly by 'decode_stacktrace.sh':
$ echo "[ 136.513051] f1+0x0/0xc [kcrash]" | \
CROSS_COMPILE=/opt/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux- \
./scripts/decode_stacktrace.sh /scratch/linux-arm64/vmlinux \
/scratch/linux-arm64 \
/nfs/debian/lib/modules/4.20.0-devel
[ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:68) kcrash
If addr2line from the toolchain is used the decoded line number is correct:
[ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:57) kcrash
Link: http://lkml.kernel.org/r/20190527083425.3763-1-ma...@linutronix.de
Signed-off-by: Manuel Traut
Acked-by: Konstantin Khlebnikov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
scripts/decode_stacktrace.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
index bcdd45df3f51..a7a36209a193 100755
--- a/scripts/decode_stacktrace.sh
+++ b/scripts/decode_stacktrace.sh
@@ -73,7 +73,7 @@ parse_symbol() {
if [[ "${cache[$module,$address]+isset}" == "isset" ]]; then
local code=${cache[$module,$address]}
else
- local code=$(addr2line -i -e "$objfile" "$address")
+ local code=$(${CROSS_COMPILE}addr2line -i -e "$objfile"
"$address")
cache[$module,$address]=$code
fi
--
2.20.1
[PATCH AUTOSEL 4.19 02/34] ASoC: ak4458: add return value for ak4458_probe
From: Viorel Suman
[ Upstream commit a8dee20d792432740509237943700fbcfc230bad ]
AK4458 is probed successfully even if AK4458 is not present - this
is caused by probe function returning no error on i2c access failure.
Return an error on probe if i2c access has failed.
Signed-off-by: Shengjiu Wang
Signed-off-by: Viorel Suman
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/ak4458.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/ak4458.c b/sound/soc/codecs/ak4458.c
index 299ada4dfaa0..58b6ca1de993 100644
--- a/sound/soc/codecs/ak4458.c
+++ b/sound/soc/codecs/ak4458.c
@@ -492,9 +492,10 @@ static void ak4458_power_on(struct ak4458_priv *ak4458)
}
}
-static void ak4458_init(struct snd_soc_component *component)
+static int ak4458_init(struct snd_soc_component *component)
{
struct ak4458_priv *ak4458 = snd_soc_component_get_drvdata(component);
+ int ret;
/* External Mute ON */
if (ak4458->mute_gpiod)
@@ -502,21 +503,21 @@ static void ak4458_init(struct snd_soc_component
*component)
ak4458_power_on(ak4458);
- snd_soc_component_update_bits(component, AK4458_00_CONTROL1,
+ ret = snd_soc_component_update_bits(component, AK4458_00_CONTROL1,
0x80, 0x80); /* ACKS bit = 1; 1000 */
+ if (ret < 0)
+ return ret;
- ak4458_rstn_control(component, 1);
+ return ak4458_rstn_control(component, 1);
}
static int ak4458_probe(struct snd_soc_component *component)
{
struct ak4458_priv *ak4458 = snd_soc_component_get_drvdata(component);
- ak4458_init(component);
-
ak4458->fs = 48000;
- return 0;
+ return ak4458_init(component);
}
static void ak4458_remove(struct snd_soc_component *component)
--
2.20.1
[PATCH AUTOSEL 5.1 32/51] ALSA: hdac: fix memory release for SST and SOF drivers
From: Amadeusz Sławiński
[ Upstream commit 6d647b736a6b1cbf2f8deab0e6a94c34a6ea9d60 ]
During the integration of HDaudio support, we changed the way in which
we get hdev in snd_hdac_ext_bus_device_init() to use one preallocated
with devm_kzalloc(), however it still left kfree(hdev) in
snd_hdac_ext_bus_device_exit(). It leads to oopses when trying to
rmmod and modprobe. Fix it, by just removing kfree call.
SOF also uses some of the snd_hdac_ functions for HDAudio support but
allocated the memory with kzalloc. A matching fix is provided
separately to align all users of the snd_hdac_ library.
Fixes: 6298542fa33b ("ALSA: hdac: remove memory allocation from
snd_hdac_ext_bus_device_init")
Reviewed-by: Takashi Iwai
Signed-off-by: Amadeusz Sławiński
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/hda/ext/hdac_ext_bus.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/hda/ext/hdac_ext_bus.c b/sound/hda/ext/hdac_ext_bus.c
index ec7715c6b0c0..c147ebe542da 100644
--- a/sound/hda/ext/hdac_ext_bus.c
+++ b/sound/hda/ext/hdac_ext_bus.c
@@ -172,7 +172,6 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_device_init);
void snd_hdac_ext_bus_device_exit(struct hdac_device *hdev)
{
snd_hdac_device_exit(hdev);
- kfree(hdev);
}
EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_device_exit);
--
2.20.1
[PATCH AUTOSEL 5.1 41/51] platform/x86: intel-vbtn: Report switch events when event wakes device
From: Mathew King
[ Upstream commit cb1921b17adbe6509538098ac431033378cd7165 ]
When a switch event, such as tablet mode/laptop mode or docked/undocked,
wakes a device make sure that the value of the swich is reported.
Without when a device is put in tablet mode from laptop mode when it is
suspended or vice versa the device will wake up but mode will be
incorrect.
Tested by suspending a device in laptop mode and putting it in tablet
mode, the device resumes and is in tablet mode. When suspending the
device in tablet mode and putting it in laptop mode the device resumes
and is in laptop mode.
Signed-off-by: Mathew King
Reviewed-by: Jett Rink
Reviewed-by: Mario Limonciello
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
---
drivers/platform/x86/intel-vbtn.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/intel-vbtn.c
b/drivers/platform/x86/intel-vbtn.c
index 06cd7e818ed5..a0d0cecff55f 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -76,12 +76,24 @@ static void notify_handler(acpi_handle handle, u32 event,
void *context)
struct platform_device *device = context;
struct intel_vbtn_priv *priv = dev_get_drvdata(>dev);
unsigned int val = !(event & 1); /* Even=press, Odd=release */
- const struct key_entry *ke_rel;
+ const struct key_entry *ke, *ke_rel;
bool autorelease;
if (priv->wakeup_mode) {
- if (sparse_keymap_entry_from_scancode(priv->input_dev, event)) {
+ ke = sparse_keymap_entry_from_scancode(priv->input_dev, event);
+ if (ke) {
pm_wakeup_hard_event(>dev);
+
+ /*
+* Switch events like tablet mode will wake the device
+* and report the new switch position to the input
+* subsystem.
+*/
+ if (ke->type == KE_SW)
+ sparse_keymap_report_event(priv->input_dev,
+ event,
+ val,
+ 0);
return;
}
goto out_unknown;
--
2.20.1
[PATCH AUTOSEL 5.1 30/51] ASoC: Intel: cht_bsw_rt5672: fix kernel oops with platform_name override
From: Pierre-Louis Bossart
[ Upstream commit 9bbc799318a34061703f2a980e2b6df7fc6760f0 ]
The platform override code uses devm_ functions to allocate memory for
the new name but the card device is not initialized. Fix by moving the
init earlier.
Fixes: f403906da05cd ("ASoC: Intel: cht_bsw_rt5672: platform name fixup
support")
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/intel/boards/cht_bsw_rt5672.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/boards/cht_bsw_rt5672.c
b/sound/soc/intel/boards/cht_bsw_rt5672.c
index 3d5a2b3a06f0..87ce3857376d 100644
--- a/sound/soc/intel/boards/cht_bsw_rt5672.c
+++ b/sound/soc/intel/boards/cht_bsw_rt5672.c
@@ -425,6 +425,7 @@ static int snd_cht_mc_probe(struct platform_device *pdev)
}
/* override plaform name, if required */
+ snd_soc_card_cht.dev = >dev;
platform_name = mach->mach_params.platform;
ret_val = snd_soc_fixup_dai_links_platform_name(_soc_card_cht,
@@ -442,7 +443,6 @@ static int snd_cht_mc_probe(struct platform_device *pdev)
snd_soc_card_set_drvdata(_soc_card_cht, drv);
/* register the soc card */
- snd_soc_card_cht.dev = >dev;
ret_val = devm_snd_soc_register_card(>dev, _soc_card_cht);
if (ret_val) {
dev_err(>dev,
--
2.20.1
[PATCH AUTOSEL 5.1 31/51] ASoC: core: move DAI pre-links initiation to snd_soc_instantiate_card
From: Tzung-Bi Shih
[ Upstream commit 70fc53734e71ce51f46dfcfd1a1c319e1cfe080c ]
Kernel crashes when an ASoC component rebinding.
The dai_link->platforms has been reset to NULL by soc_cleanup_platform()
in soc_cleanup_card_resources() when un-registering component. However,
it has no chance to re-allocate the dai_link->platforms when registering
the component again.
Move the DAI pre-links initiation from snd_soc_register_card() to
snd_soc_instantiate_card() to make sure all DAI pre-links get initiated
when component rebinding.
As an example, by using the following commands:
- echo -n max98357a > /sys/bus/platform/drivers/max98357a/unbind
- echo -n max98357a > /sys/bus/platform/drivers/max98357a/bind
Got the error message:
"Unable to handle kernel NULL pointer dereference at virtual address".
The call trace:
snd_soc_is_matching_component+0x30/0x6c
soc_bind_dai_link+0x16c/0x240
snd_soc_bind_card+0x1e4/0xb10
snd_soc_add_component+0x270/0x300
snd_soc_register_component+0x54/0x6c
Signed-off-by: Tzung-Bi Shih
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/soc-core.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index a4668a788ed5..9df3bdeb5c47 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2069,6 +2069,16 @@ static int snd_soc_instantiate_card(struct snd_soc_card
*card)
int ret, i, order;
mutex_lock(_mutex);
+ for_each_card_prelinks(card, i, dai_link) {
+ ret = soc_init_dai_link(card, dai_link);
+ if (ret) {
+ soc_cleanup_platform(card);
+ dev_err(card->dev, "ASoC: failed to init link %s: %d\n",
+ dai_link->name, ret);
+ mutex_unlock(_mutex);
+ return ret;
+ }
+ }
mutex_lock_nested(>mutex, SND_SOC_CARD_CLASS_INIT);
card->dapm.bias_level = SND_SOC_BIAS_OFF;
@@ -2793,26 +2803,9 @@ static int snd_soc_bind_card(struct snd_soc_card *card)
*/
int snd_soc_register_card(struct snd_soc_card *card)
{
- int i, ret;
- struct snd_soc_dai_link *link;
-
if (!card->name || !card->dev)
return -EINVAL;
- mutex_lock(_mutex);
- for_each_card_prelinks(card, i, link) {
-
- ret = soc_init_dai_link(card, link);
- if (ret) {
- soc_cleanup_platform(card);
- dev_err(card->dev, "ASoC: failed to init link %s\n",
- link->name);
- mutex_unlock(_mutex);
- return ret;
- }
- }
- mutex_unlock(_mutex);
-
dev_set_drvdata(card->dev, card);
snd_soc_initialize_card_lists(card);
--
2.20.1
[PATCH AUTOSEL 5.1 45/51] arm64: tlbflush: Ensure start/end of address range are aligned to stride
From: Will Deacon
[ Upstream commit 01d57485fcdb9f9101a10a18e32d5f8b023cab86 ]
Since commit 3d65b6bbc01e ("arm64: tlbi: Set MAX_TLBI_OPS to
PTRS_PER_PTE"), we resort to per-ASID invalidation when attempting to
perform more than PTRS_PER_PTE invalidation instructions in a single
call to __flush_tlb_range(). Whilst this is beneficial, the mmu_gather
code does not ensure that the end address of the range is rounded-up
to the stride when freeing intermediate page tables in pXX_free_tlb(),
which defeats our range checking.
Align the bounds passed into __flush_tlb_range().
Cc: Catalin Marinas
Cc: Peter Zijlstra
Reported-by: Hanjun Guo
Tested-by: Hanjun Guo
Reviewed-by: Hanjun Guo
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
---
arch/arm64/include/asm/tlbflush.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index 3a1870228946..dff8f9ea5754 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -195,6 +195,9 @@ static inline void __flush_tlb_range(struct vm_area_struct
*vma,
unsigned long asid = ASID(vma->vm_mm);
unsigned long addr;
+ start = round_down(start, stride);
+ end = round_up(end, stride);
+
if ((end - start) >= (MAX_TLBI_OPS * stride)) {
flush_tlb_mm(vma->vm_mm);
return;
--
2.20.1
[PATCH AUTOSEL 4.19 09/34] drm/mediatek: unbind components in mtk_drm_unbind()
From: Hsin-Yi Wang
[ Upstream commit f0fd848342802bc0f74620d387eead53e8905804 ]
Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will
trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind
won't actually unbind components. During the next bind,
mtk_drm_kms_init() is called, and the components are added back.
.unbind() should call mtk_drm_kms_deinit() to unbind components.
And since component_master_del() in .remove() will trigger .unbind(),
which will also unregister device, it's fine to remove original functions
called here.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Hsin-Yi Wang
Signed-off-by: CK Hu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 47ec604289b7..bbe57ad9acf1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -390,6 +390,7 @@ static void mtk_drm_unbind(struct device *dev)
struct mtk_drm_private *private = dev_get_drvdata(dev);
drm_dev_unregister(private->drm);
+ mtk_drm_kms_deinit(private->drm);
drm_dev_put(private->drm);
private->drm = NULL;
}
@@ -559,13 +560,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
static int mtk_drm_remove(struct platform_device *pdev)
{
struct mtk_drm_private *private = platform_get_drvdata(pdev);
- struct drm_device *drm = private->drm;
int i;
- drm_dev_unregister(drm);
- mtk_drm_kms_deinit(drm);
- drm_dev_put(drm);
-
component_master_del(>dev, _drm_ops);
pm_runtime_disable(>dev);
of_node_put(private->mutex_node);
--
2.20.1
[PATCH AUTOSEL 5.1 50/51] module: Fix livepatch/ftrace module text permissions race
From: Josh Poimboeuf
[ Upstream commit 9f255b632bf12c4dd7fc31caee89aa991ef75176 ]
It's possible for livepatch and ftrace to be toggling a module's text
permissions at the same time, resulting in the following panic:
BUG: unable to handle page fault for address: c005b1d9
#PF: supervisor write access in kernel mode
#PF: error_code(0x0003) - permissions violation
PGD 3ea0c067 P4D 3ea0c067 PUD 3ea0e067 PMD 3cc13067 PTE 3b8a1061
Oops: 0003 [#1] PREEMPT SMP PTI
CPU: 1 PID: 453 Comm: insmod Tainted: G O K 5.2.0-rc1-a188339ca5
#1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-20181126_142135-anatol 04/01/2014
RIP: 0010:apply_relocate_add+0xbe/0x14c
Code: fa 0b 74 21 48 83 fa 18 74 38 48 83 fa 0a 75 40 eb 08 48 83 38 00 74 33
eb 53 83 38 00 75 4e 89 08 89 c8 eb 0a 83 38 00 75 43 <89> 08 48 63 c1 48 39 c8
74 2e eb 48 83 38 00 75 32 48 29 c1 89 08
RSP: 0018:b223c00dbb10 EFLAGS: 00010246
RAX: c005b1d9 RBX: RCX: 8b200060
RDX: 000b RSI: 004b000b RDI: 96bdfcd33000
RBP: b223c00dbb38 R08: c005d040 R09: c005c1f0
R10: 96bdfcd33c40 R11: 96bdfcd33b80 R12: 0018
R13: c005c1f0 R14: c005e708 R15: 8b2fbc74
FS: 7f5f447beba8() GS:96bdff90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: c005b1d9 CR3: 3cedc002 CR4: 00360ea0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
klp_init_object_loaded+0x10f/0x219
? preempt_latency_start+0x21/0x57
klp_enable_patch+0x662/0x809
? virt_to_head_page+0x3a/0x3c
? kfree+0x8c/0x126
patch_init+0x2ed/0x1000 [livepatch_test02]
? 0xc006
do_one_initcall+0x9f/0x1c5
? kmem_cache_alloc_trace+0xc4/0xd4
? do_init_module+0x27/0x210
do_init_module+0x5f/0x210
load_module+0x1c41/0x2290
? fsnotify_path+0x3b/0x42
? strstarts+0x2b/0x2b
? kernel_read+0x58/0x65
__do_sys_finit_module+0x9f/0xc3
? __do_sys_finit_module+0x9f/0xc3
__x64_sys_finit_module+0x1a/0x1c
do_syscall_64+0x52/0x61
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The above panic occurs when loading two modules at the same time with
ftrace enabled, where at least one of the modules is a livepatch module:
CPU0CPU1
klp_enable_patch()
klp_init_object_loaded()
module_disable_ro()
ftrace_module_enable()
ftrace_arch_code_modify_post_process()
set_all_modules_text_ro()
klp_write_object_relocations()
apply_relocate_add()
*patches read-only code* - BOOM
A similar race exists when toggling ftrace while loading a livepatch
module.
Fix it by ensuring that the livepatch and ftrace code patching
operations -- and their respective permissions changes -- are protected
by the text_mutex.
Link:
http://lkml.kernel.org/r/ab43d56ab909469ac5d2520c5d944ad6d4abd476.1560474114.git.jpoim...@redhat.com
Reported-by: Johannes Erdfelt
Fixes: 444d13ff10fb ("modules: add ro_after_init support")
Acked-by: Jessica Yu
Reviewed-by: Petr Mladek
Reviewed-by: Miroslav Benes
Signed-off-by: Josh Poimboeuf
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
---
kernel/livepatch/core.c | 6 ++
kernel/trace/ftrace.c | 10 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index eb0ee10a1981..05d5b0afc864 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include "core.h"
#include "patch.h"
@@ -746,16 +747,21 @@ static int klp_init_object_loaded(struct klp_patch *patch,
struct klp_func *func;
int ret;
+ mutex_lock(_mutex);
+
module_disable_ro(patch->mod);
ret = klp_write_object_relocations(patch->mod, obj);
if (ret) {
module_enable_ro(patch->mod, true);
+ mutex_unlock(_mutex);
return ret;
}
arch_klp_init_object_loaded(patch, obj);
module_enable_ro(patch->mod, true);
+ mutex_unlock(_mutex);
+
klp_for_each_func(obj, func) {
ret = klp_find_object_symbol(obj->name, func->old_name,
func->old_sympos,
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 538f0b1c7ea2..045e7f46a74a 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -2614,10 +2615,12 @@ static void ftrace_run_update_code(int command)
{
int ret;
+ mutex_lock(_mutex);
+
ret =
[PATCH AUTOSEL 4.19 07/34] ASoC: sun4i-codec: fix first delay on Speaker
From: Georgii Staroselskii
[ Upstream commit 1f2675f6655838aaf910f911fd0abc821e3ff3df ]
Allwinner DAC seems to have a delay in the Speaker audio routing. When
playing a sound for the first time, the sound gets chopped. On a second
play the sound is played correctly. After some time (~5s) the issue gets
back.
This commit seems to be fixing the same issue as bf14da7 but
for another codepath.
This is the DTS that was used to debug the problem.
{
allwinner,pa-gpios = <_pio 0 11 GPIO_ACTIVE_HIGH>; /* PL11 */
allwinner,audio-routing =
"Speaker", "LINEOUT";
status = "okay";
}
Signed-off-by: Georgii Staroselskii
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/sunxi/sun4i-codec.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 9a3cb7704810..73f242460afd 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1210,6 +1210,15 @@ static int sun4i_codec_spk_event(struct
snd_soc_dapm_widget *w,
gpiod_set_value_cansleep(scodec->gpio_pa,
!!SND_SOC_DAPM_EVENT_ON(event));
+ if (SND_SOC_DAPM_EVENT_ON(event)) {
+ /*
+* Need a delay to wait for DAC to push the data. 700ms seems
+* to be the best compromise not to feel this delay while
+* playing a sound.
+*/
+ msleep(700);
+ }
+
return 0;
}
--
2.20.1
[PATCH AUTOSEL 5.1 51/51] ftrace: Fix NULL pointer dereference in free_ftrace_func_mapper()
From: Wei Li
[ Upstream commit 04e03d9a616c19a47178eaca835358610e63a1dd ]
The mapper may be NULL when called from register_ftrace_function_probe()
with probe->data == NULL.
This issue can be reproduced as follow (it may be covered by compiler
optimization sometime):
/ # cat /sys/kernel/debug/tracing/set_ftrace_filter
all functions enabled
/ # echo foo_bar:dump > /sys/kernel/debug/tracing/set_ftrace_filter
[ 206.949100] Unable to handle kernel NULL pointer dereference at virtual
address
[ 206.952402] Mem abort info:
[ 206.952819] ESR = 0x9606
[ 206.955326] Exception class = DABT (current EL), IL = 32 bits
[ 206.955844] SET = 0, FnV = 0
[ 206.956272] EA = 0, S1PTW = 0
[ 206.956652] Data abort info:
[ 206.957320] ISV = 0, ISS = 0x0006
[ 206.959271] CM = 0, WnR = 0
[ 206.959938] user pgtable: 4k pages, 48-bit VAs, pgdp=000419f3a000
[ 206.960483] [] pgd=000411a87003, pud=000411a83003,
pmd=
[ 206.964953] Internal error: Oops: 9606 [#1] SMP
[ 206.971122] Dumping ftrace buffer:
[ 206.973677](ftrace buffer empty)
[ 206.975258] Modules linked in:
[ 206.976631] Process sh (pid: 281, stack limit = 0x(ptrval))
[ 206.978449] CPU: 10 PID: 281 Comm: sh Not tainted 5.2.0-rc1+ #17
[ 206.978955] Hardware name: linux,dummy-virt (DT)
[ 206.979883] pstate: 6005 (nZCv daif -PAN -UAO)
[ 206.980499] pc : free_ftrace_func_mapper+0x2c/0x118
[ 206.980874] lr : ftrace_count_free+0x68/0x80
[ 206.982539] sp : 182f3ab0
[ 206.983102] x29: 182f3ab0 x28: 8003d0ec1700
[ 206.983632] x27: 13054b40 x26: 0001
[ 206.984000] x25: 1385f000 x24:
[ 206.984394] x23: 13453000 x22: 13054000
[ 206.984775] x21: x20: 1385fe28
[ 206.986575] x19: 13872c30 x18:
[ 206.987111] x17: x16:
[ 206.987491] x15: ffb0 x14:
[ 206.987850] x13: 0017430e x12: 0580
[ 206.988251] x11: x10:
[ 206.988740] x9 : x8 : 13917550
[ 206.990198] x7 : 12fac2e8 x6 : 12fac000
[ 206.991008] x5 : 103da588 x4 : 0001
[ 206.991395] x3 : 0001 x2 : 13872a28
[ 206.991771] x1 : x0 :
[ 206.992557] Call trace:
[ 206.993101] free_ftrace_func_mapper+0x2c/0x118
[ 206.994827] ftrace_count_free+0x68/0x80
[ 206.995238] release_probe+0xfc/0x1d0
[ 206.99] register_ftrace_function_probe+0x4a8/0x868
[ 206.995923] ftrace_trace_probe_callback.isra.4+0xb8/0x180
[ 206.996330] ftrace_dump_callback+0x50/0x70
[ 206.996663] ftrace_regex_write.isra.29+0x290/0x3a8
[ 206.997157] ftrace_filter_write+0x44/0x60
[ 206.998971] __vfs_write+0x64/0xf0
[ 206.999285] vfs_write+0x14c/0x2f0
[ 206.999591] ksys_write+0xbc/0x1b0
[ 206.999888] __arm64_sys_write+0x3c/0x58
[ 207.000246] el0_svc_common.constprop.0+0x408/0x5f0
[ 207.000607] el0_svc_handler+0x144/0x1c8
[ 207.000916] el0_svc+0x8/0xc
[ 207.003699] Code: aa0003f8 a9025bf5 aa0103f5 f946ea80 (f9400303)
[ 207.008388] ---[ end trace 7b6d11b5f542bdf1 ]---
[ 207.010126] Kernel panic - not syncing: Fatal exception
[ 207.011322] SMP: stopping secondary CPUs
[ 207.013956] Dumping ftrace buffer:
[ 207.014595](ftrace buffer empty)
[ 207.015632] Kernel Offset: disabled
[ 207.017187] CPU features: 0x002,20006008
[ 207.017985] Memory Limit: none
[ 207.019825] ---[ end Kernel panic - not syncing: Fatal exception ]---
Link: http://lkml.kernel.org/r/20190606031754.10798-1-liwei...@huawei.com
Signed-off-by: Wei Li
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
---
kernel/trace/ftrace.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 045e7f46a74a..2469d54b3e43 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4230,10 +4230,13 @@ void free_ftrace_func_mapper(struct ftrace_func_mapper
*mapper,
struct ftrace_func_entry *entry;
struct ftrace_func_map *map;
struct hlist_head *hhd;
- int size = 1 << mapper->hash.size_bits;
- int i;
+ int size, i;
+
+ if (!mapper)
+ return;
if (free_func && mapper->hash.count) {
+ size = 1 << mapper->hash.size_bits;
for (i = 0; i < size; i++) {
hhd = >hash.buckets[i];
hlist_for_each_entry(entry, hhd, hlist) {
--
2.20.1
Re: [PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
> On Jun 25, 2019, at 8:36 PM, Andy Lutomirski wrote: > > On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit wrote: >> To improve TLB shootdown performance, flush the remote and local TLBs >> concurrently. Introduce flush_tlb_multi() that does so. The current >> flush_tlb_others() interface is kept, since paravirtual interfaces need >> to be adapted first before it can be removed. This is left for future >> work. In such PV environments, TLB flushes are not performed, at this >> time, concurrently. > > Would it be straightforward to have a default PV flush_tlb_multi() > that uses flush_tlb_others() under the hood? I prefer not to have a default PV implementation that should anyhow go away. I can create unoptimized untested versions for Xen and Hyper-V, if you want.
[PATCH AUTOSEL 4.19 17/34] usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i]
From: Young Xiao <92siuy...@gmail.com>
[ Upstream commit 62fd0e0a24abeebe2c19fce49dd5716d9b62042d ]
There is no deallocation of fusb300->ep[i] elements, allocated at
fusb300_probe.
The patch adds deallocation of fusb300->ep array elements.
Signed-off-by: Young Xiao <92siuy...@gmail.com>
Signed-off-by: Felipe Balbi
Signed-off-by: Sasha Levin
---
drivers/usb/gadget/udc/fusb300_udc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/gadget/udc/fusb300_udc.c
b/drivers/usb/gadget/udc/fusb300_udc.c
index 263804d154a7..00e3f66836a9 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -1342,12 +1342,15 @@ static const struct usb_gadget_ops fusb300_gadget_ops =
{
static int fusb300_remove(struct platform_device *pdev)
{
struct fusb300 *fusb300 = platform_get_drvdata(pdev);
+ int i;
usb_del_gadget_udc(>gadget);
iounmap(fusb300->reg);
free_irq(platform_get_irq(pdev, 0), fusb300);
fusb300_free_request(>ep[0]->ep, fusb300->ep0_req);
+ for (i = 0; i < FUSB300_MAX_NUM_EP; i++)
+ kfree(fusb300->ep[i]);
kfree(fusb300);
return 0;
@@ -1491,6 +1494,8 @@ static int fusb300_probe(struct platform_device *pdev)
if (fusb300->ep0_req)
fusb300_free_request(>ep[0]->ep,
fusb300->ep0_req);
+ for (i = 0; i < FUSB300_MAX_NUM_EP; i++)
+ kfree(fusb300->ep[i]);
kfree(fusb300);
}
if (reg)
--
2.20.1
[PATCH AUTOSEL 4.19 01/34] ASoC : cs4265 : readable register too low
From: Matt Flax
[ Upstream commit f3df05c805983427319eddc2411a2105ee1757cf ]
The cs4265_readable_register function stopped short of the maximum
register.
An example bug is taken from :
https://github.com/Audio-Injector/Ultra/issues/25
Where alsactl store fails with :
Cannot read control '2,0,0,C Data Buffer,0': Input/output error
This patch fixes the bug by setting the cs4265 to have readable
registers up to the maximum hardware register CS4265_MAX_REGISTER.
Signed-off-by: Matt Flax
Reviewed-by: Charles Keepax
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/cs4265.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/cs4265.c b/sound/soc/codecs/cs4265.c
index 407554175282..68d18aca397d 100644
--- a/sound/soc/codecs/cs4265.c
+++ b/sound/soc/codecs/cs4265.c
@@ -60,7 +60,7 @@ static const struct reg_default cs4265_reg_defaults[] = {
static bool cs4265_readable_register(struct device *dev, unsigned int reg)
{
switch (reg) {
- case CS4265_CHIP_ID ... CS4265_SPDIF_CTL2:
+ case CS4265_CHIP_ID ... CS4265_MAX_REGISTER:
return true;
default:
return false;
--
2.20.1
[PATCH AUTOSEL 4.19 05/34] spi: bitbang: Fix NULL pointer dereference in spi_unregister_master
From: YueHaibing
[ Upstream commit 5caaf29af5ca82d5da8bc1d0ad07d9e664ccf1d8 ]
If spi_register_master fails in spi_bitbang_start
because device_add failure, We should return the
error code other than 0, otherwise calling
spi_bitbang_stop may trigger NULL pointer dereference
like this:
BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0
Read of size 8 at addr by task syz-executor.0/3661
CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
04/01/2014
Call Trace:
dump_stack+0xa9/0x10e
? __list_del_entry_valid+0x45/0xd0
? __list_del_entry_valid+0x45/0xd0
__kasan_report+0x171/0x18d
? __list_del_entry_valid+0x45/0xd0
kasan_report+0xe/0x20
__list_del_entry_valid+0x45/0xd0
spi_unregister_controller+0x99/0x1b0
spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp]
? 0xc1128000
? klist_next+0x131/0x1e0
? driver_detach+0x40/0x40 [parport]
port_check+0x3b/0x50 [parport]
bus_for_each_dev+0x115/0x180
? subsys_dev_iter_exit+0x20/0x20
__parport_register_driver+0x1f0/0x210 [parport]
? 0xc115
do_one_initcall+0xb9/0x3b5
? perf_trace_initcall_level+0x270/0x270
? kasan_unpoison_shadow+0x30/0x40
? kasan_unpoison_shadow+0x30/0x40
do_init_module+0xe0/0x330
load_module+0x38eb/0x4270
? module_frob_arch_sections+0x20/0x20
? kernel_read_file+0x188/0x3f0
? find_held_lock+0x6d/0xd0
? fput_many+0x1a/0xe0
? __do_sys_finit_module+0x162/0x190
__do_sys_finit_module+0x162/0x190
? __ia32_sys_init_module+0x40/0x40
? __mutex_unlock_slowpath+0xb4/0x3f0
? wait_for_completion+0x240/0x240
? vfs_write+0x160/0x2a0
? lockdep_hardirqs_off+0xb5/0x100
? mark_held_locks+0x1a/0x90
? do_syscall_64+0x14/0x2a0
do_syscall_64+0x72/0x2a0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Reported-by: Hulk Robot
Fixes: 702a4879ec33 ("spi: bitbang: Let spi_bitbang_start() take a reference to
master")
Signed-off-by: YueHaibing
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Axel Lin
Reviewed-by: Mukesh Ojha
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi-bitbang.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-bitbang.c b/drivers/spi/spi-bitbang.c
index f29176000b8d..06cf9388e74f 100644
--- a/drivers/spi/spi-bitbang.c
+++ b/drivers/spi/spi-bitbang.c
@@ -416,7 +416,7 @@ int spi_bitbang_start(struct spi_bitbang *bitbang)
if (ret)
spi_master_put(master);
- return 0;
+ return ret;
}
EXPORT_SYMBOL_GPL(spi_bitbang_start);
--
2.20.1
[PATCH AUTOSEL 4.19 03/34] ASoC: soc-pcm: BE dai needs prepare when pause release after resume
From: Libin Yang [ Upstream commit 5087a8f17df868601cd7568299e91c28086d2b45 ] If playback/capture is paused and system enters S3, after system returns from suspend, BE dai needs to call prepare() callback when playback/capture is released from pause if RESUME_INFO flag is not set. Currently, the dpcm_be_dai_prepare() function will block calling prepare() if the pcm is in SND_SOC_DPCM_STATE_PAUSED state. This will cause the following test case fail if the pcm uses BE: playback -> pause -> S3 suspend -> S3 resume -> pause release The playback may exit abnormally when pause is released because the BE dai prepare() is not called. This patch allows dpcm_be_dai_prepare() to call dai prepare() callback in SND_SOC_DPCM_STATE_PAUSED state. Signed-off-by: Libin Yang Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/soc-pcm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 33060af18b5a..6566c8831a96 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -2451,7 +2451,8 @@ int dpcm_be_dai_prepare(struct snd_soc_pcm_runtime *fe, int stream) if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP) && - (be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND)) + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND) && + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED)) continue; dev_dbg(be->dev, "ASoC: prepare BE %s\n", -- 2.20.1
Re: [PATCH v3 1/3] scsi: ufs: Introduce vops for resetting device
On Tue 25 Jun 05:41 PDT 2019, Alim Akhtar wrote:
> Hi Bjorn,
> Are you planning to address Bean's comment on patch#2 and want to
> re-spin this series?
> I am ok with taking this patch as it is and take a Softreset patch as a
> separate patch.
>
I still intend to attempt to implement a softreset "fallback", per
Bean's suggestion - just haven't found the time yet. But I would be
happy to see these patches merged in the meantime, as they do resolve
the issue of failing to being up the UFS link on a significant number of
Qualcomm devices.
I think it's best if you take patch 1 and 2 through your tree and we
take the dts patch through the Qualcomm/arm-soc tree.
Thanks,
Bjorn
> On 6/8/19 10:34 AM, Bjorn Andersson wrote:
> > Some UFS memory devices needs their reset line toggled in order to get
> > them into a good state for initialization. Provide a new vops to allow
> > the platform driver to implement this operation.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> feel free to add
> Reviewed-by: Alim Akhtar
> >
> > Changes since v2:
> > - New patch, to allow moving implementation to platform driver
> >
> > drivers/scsi/ufs/ufshcd.c | 6 ++
> > drivers/scsi/ufs/ufshcd.h | 8
> > 2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index 04d3686511c8..ee895a625456 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -6191,6 +6191,9 @@ static int ufshcd_reset_and_restore(struct ufs_hba
> > *hba)
> > int retries = MAX_HOST_RESET_RETRIES;
> >
> > do {
> > + /* Reset the attached device */
> > + ufshcd_vops_device_reset(hba);
> > +
> > err = ufshcd_host_reset_and_restore(hba);
> > } while (err && --retries);
> >
> > @@ -8322,6 +8325,9 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem
> > *mmio_base, unsigned int irq)
> > goto exit_gating;
> > }
> >
> > + /* Reset the attached device */
> > + ufshcd_vops_device_reset(hba);
> > +
> > /* Host controller enable */
> > err = ufshcd_hba_enable(hba);
> > if (err) {
> > diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> > index 994d73d03207..cd8139052ed6 100644
> > --- a/drivers/scsi/ufs/ufshcd.h
> > +++ b/drivers/scsi/ufs/ufshcd.h
> > @@ -298,6 +298,7 @@ struct ufs_pwr_mode_info {
> >* @resume: called during host controller PM callback
> >* @dbg_register_dump: used to dump controller debug information
> >* @phy_initialization: used to initialize phys
> > + * @device_reset: called to issue a reset pulse on the UFS device
> >*/
> > struct ufs_hba_variant_ops {
> > const char *name;
> > @@ -326,6 +327,7 @@ struct ufs_hba_variant_ops {
> > int (*resume)(struct ufs_hba *, enum ufs_pm_op);
> > void(*dbg_register_dump)(struct ufs_hba *hba);
> > int (*phy_initialization)(struct ufs_hba *);
> > + void(*device_reset)(struct ufs_hba *);
> > };
> >
> > /* clock gating state */
> > @@ -1045,6 +1047,12 @@ static inline void
> > ufshcd_vops_dbg_register_dump(struct ufs_hba *hba)
> > hba->vops->dbg_register_dump(hba);
> > }
> >
> > +static inline void ufshcd_vops_device_reset(struct ufs_hba *hba)
> > +{
> > + if (hba->vops && hba->vops->device_reset)
> > + hba->vops->device_reset(hba);
> > +}
> > +
> > extern struct ufs_pm_lvl_states ufs_pm_lvl_states[];
> >
> > /*
> >
[PATCH AUTOSEL 4.19 32/34] tracing: avoid build warning with HAVE_NOP_MCOUNT
From: Vasily Gorbik
[ Upstream commit cbdaeaf050b730ea02e9ab4ff844ce54d85dbe1d ]
Selecting HAVE_NOP_MCOUNT enables -mnop-mcount (if gcc supports it)
and sets CC_USING_NOP_MCOUNT. Reuse __is_defined (which is suitable for
testing CC_USING_* defines) to avoid conditional compilation and fix
the following gcc 9 warning on s390:
kernel/trace/ftrace.c:2514:1: warning: ‘ftrace_code_disable’ defined
but not used [-Wunused-function]
Link:
http://lkml.kernel.org/r/patch.git-1a82d13f33ac.your-ad-here.call-01559732716-ext-6629@work.hours
Fixes: 2f4df0017baed ("tracing: Add -mcount-nop option support")
Signed-off-by: Vasily Gorbik
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
---
kernel/trace/ftrace.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 1688782f3dfb..90348b343460 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2952,14 +2952,13 @@ static int ftrace_update_code(struct module *mod,
struct ftrace_page *new_pgs)
p = >records[i];
p->flags = rec_flags;
-#ifndef CC_USING_NOP_MCOUNT
/*
* Do the initial record conversion from mcount jump
* to the NOP instructions.
*/
- if (!ftrace_code_disable(mod, p))
+ if (!__is_defined(CC_USING_NOP_MCOUNT) &&
+ !ftrace_code_disable(mod, p))
break;
-#endif
update_cnt++;
}
--
2.20.1
[PATCH AUTOSEL 4.19 18/34] usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC
From: Alexandre Belloni [ Upstream commit fbc318afadd6e7ae2252d6158cf7d0c5a2132f7d ] Gadget drivers may queue request in interrupt context. This would lead to a descriptor allocation in that context. In that case we would hit BUG_ON(in_interrupt()) in __get_vm_area_node. Also remove the unnecessary cast. Acked-by: Sylvain Lemieux Tested-by: James Grant Signed-off-by: Alexandre Belloni Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin --- drivers/usb/gadget/udc/lpc32xx_udc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c b/drivers/usb/gadget/udc/lpc32xx_udc.c index b0781771704e..eafc2a00c96a 100644 --- a/drivers/usb/gadget/udc/lpc32xx_udc.c +++ b/drivers/usb/gadget/udc/lpc32xx_udc.c @@ -922,8 +922,7 @@ static struct lpc32xx_usbd_dd_gad *udc_dd_alloc(struct lpc32xx_udc *udc) dma_addr_t dma; struct lpc32xx_usbd_dd_gad *dd; - dd = (struct lpc32xx_usbd_dd_gad *) dma_pool_alloc( - udc->dd_cache, (GFP_KERNEL | GFP_DMA), ); + dd = dma_pool_alloc(udc->dd_cache, GFP_ATOMIC | GFP_DMA, ); if (dd) dd->this_dma = dma; -- 2.20.1
[PATCH AUTOSEL 4.19 20/34] SoC: rt274: Fix internal jack assignment in set_jack callback
From: Amadeusz Sławiński
[ Upstream commit 04268bf2757a125616b6c2140e6250f43b7b737a ]
When we call snd_soc_component_set_jack(component, NULL, NULL) we should
set rt274->jack to passed jack, so when interrupt is triggered it calls
snd_soc_jack_report(rt274->jack, ...) with proper value.
This fixes problem in machine where in register, we call
snd_soc_register(component, , NULL), which just calls
rt274_mic_detect via callback.
Now when machine driver is removed "headset" will be gone, so we
need to tell codec driver that it's gone with:
snd_soc_register(component, NULL, NULL), but we also need to be able
to handle NULL jack argument here gracefully.
If we don't set it to NULL, next time the rt274_irq runs it will call
snd_soc_jack_report with first argument being invalid pointer and there
will be Oops.
Signed-off-by: Amadeusz Sławiński
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/rt274.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/rt274.c b/sound/soc/codecs/rt274.c
index 18a931c25ca5..f09f2d87ac60 100644
--- a/sound/soc/codecs/rt274.c
+++ b/sound/soc/codecs/rt274.c
@@ -398,6 +398,8 @@ static int rt274_mic_detect(struct snd_soc_component
*component,
{
struct rt274_priv *rt274 = snd_soc_component_get_drvdata(component);
+ rt274->jack = jack;
+
if (jack == NULL) {
/* Disable jack detection */
regmap_update_bits(rt274->regmap, RT274_EAPD_GPIO_IRQ_CTRL,
@@ -405,7 +407,6 @@ static int rt274_mic_detect(struct snd_soc_component
*component,
return 0;
}
- rt274->jack = jack;
regmap_update_bits(rt274->regmap, RT274_EAPD_GPIO_IRQ_CTRL,
RT274_IRQ_EN, RT274_IRQ_EN);
--
2.20.1
[PATCH AUTOSEL 4.19 31/34] mm/mlock.c: change count_mm_mlocked_page_nr return type
From: swkhack
[ Upstream commit 0874bb49bb21bf24deda853e8bf61b8325e24bcb ]
On a 64-bit machine the value of "vma->vm_end - vma->vm_start" may be
negative when using 32 bit ints and the "count >> PAGE_SHIFT"'s result
will be wrong. So change the local variable and return value to
unsigned long to fix the problem.
Link: http://lkml.kernel.org/r/20190513023701.83056-1-swkh...@gmail.com
Fixes: 0cf2f6f6dc60 ("mm: mlock: check against vma for actual mlock() size")
Signed-off-by: swkhack
Acked-by: Michal Hocko
Reviewed-by: Andrew Morton
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
mm/mlock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/mlock.c b/mm/mlock.c
index 41cc47e28ad6..0ab8250af1f8 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -636,11 +636,11 @@ static int apply_vma_lock_flags(unsigned long start,
size_t len,
* is also counted.
* Return value: previously mlocked page counts
*/
-static int count_mm_mlocked_page_nr(struct mm_struct *mm,
+static unsigned long count_mm_mlocked_page_nr(struct mm_struct *mm,
unsigned long start, size_t len)
{
struct vm_area_struct *vma;
- int count = 0;
+ unsigned long count = 0;
if (mm == NULL)
mm = current->mm;
--
2.20.1
[PATCH AUTOSEL 4.19 23/34] drm: panel-orientation-quirks: Add quirk for GPD MicroPC
From: Hans de Goede
[ Upstream commit 652b8b086538c8a10de5aa5cbdaef79333b46358 ]
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_micropc data struct may very well need to be updated
with some extra bios-dates in the future.
Acked-by: Maxime Ripard
Signed-off-by: Hans de Goede
Link:
https://patchwork.freedesktop.org/patch/msgid/20190524125759.14131-2-hdego...@redhat.com
(cherry picked from commit f2f2bb60d998abde10de7e483ef9e17639892450)
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 088363675940..b44bed554211 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -42,6 +42,14 @@ static const struct drm_dmi_panel_orientation_data
asus_t100ha = {
.orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
};
+static const struct drm_dmi_panel_orientation_data gpd_micropc = {
+ .width = 720,
+ .height = 1280,
+ .bios_dates = (const char * const []){ "04/26/2019",
+ NULL },
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
static const struct drm_dmi_panel_orientation_data gpd_pocket = {
.width = 1200,
.height = 1920,
@@ -93,6 +101,14 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
},
.driver_data = (void *)_t100ha,
+ }, {/* GPD MicroPC (generic strings, also match on bios date) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
+ },
+ .driver_data = (void *)_micropc,
}, {/*
* GPD Pocket, note that the the DMI data is less generic then
* it seems, devices with a board-vendor of "AMI Corporation"
--
2.20.1
[PATCH AUTOSEL 4.19 24/34] platform/x86: asus-wmi: Only Tell EC the OS will handle display hotkeys from asus_nb_wmi
From: Hans de Goede
[ Upstream commit 401fee8195d401b2b94dee57383f627050724d5b ]
Commit 78f3ac76d9e5 ("platform/x86: asus-wmi: Tell the EC the OS will
handle the display off hotkey") causes the backlight to be permanently off
on various EeePC laptop models using the eeepc-wmi driver (Asus EeePC
1015BX, Asus EeePC 1025C).
The asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL) call added
by that commit is made conditional in this commit and only enabled in
the quirk_entry structs in the asus-nb-wmi driver fixing the broken
display / backlight on various EeePC laptop models.
Cc: João Paulo Rechi Vita
Fixes: 78f3ac76d9e5 ("platform/x86: asus-wmi: Tell the EC the OS will handle
the display off hotkey")
Signed-off-by: Hans de Goede
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
---
drivers/platform/x86/asus-nb-wmi.c | 8
drivers/platform/x86/asus-wmi.c| 2 +-
drivers/platform/x86/asus-wmi.h| 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index b6f2ff95c3ed..59f3a37a44d7 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -78,10 +78,12 @@ static bool asus_q500a_i8042_filter(unsigned char data,
unsigned char str,
static struct quirk_entry quirk_asus_unknown = {
.wapf = 0,
+ .wmi_backlight_set_devstate = true,
};
static struct quirk_entry quirk_asus_q500a = {
.i8042_filter = asus_q500a_i8042_filter,
+ .wmi_backlight_set_devstate = true,
};
/*
@@ -92,26 +94,32 @@ static struct quirk_entry quirk_asus_q500a = {
static struct quirk_entry quirk_asus_x55u = {
.wapf = 4,
.wmi_backlight_power = true,
+ .wmi_backlight_set_devstate = true,
.no_display_toggle = true,
};
static struct quirk_entry quirk_asus_wapf4 = {
.wapf = 4,
+ .wmi_backlight_set_devstate = true,
};
static struct quirk_entry quirk_asus_x200ca = {
.wapf = 2,
+ .wmi_backlight_set_devstate = true,
};
static struct quirk_entry quirk_asus_ux303ub = {
.wmi_backlight_native = true,
+ .wmi_backlight_set_devstate = true,
};
static struct quirk_entry quirk_asus_x550lb = {
+ .wmi_backlight_set_devstate = true,
.xusb2pr = 0x01D9,
};
static struct quirk_entry quirk_asus_forceals = {
+ .wmi_backlight_set_devstate = true,
.wmi_force_als_set = true,
};
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index db3556dc90d1..22eac449d3a3 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -2231,7 +2231,7 @@ static int asus_wmi_add(struct platform_device *pdev)
err = asus_wmi_backlight_init(asus);
if (err && err != -ENODEV)
goto fail_backlight;
- } else
+ } else if (asus->driver->quirks->wmi_backlight_set_devstate)
err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL);
status = wmi_install_notify_handler(asus->driver->event_guid,
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 6c1311f4b04d..57a79bddb286 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -44,6 +44,7 @@ struct quirk_entry {
bool store_backlight_power;
bool wmi_backlight_power;
bool wmi_backlight_native;
+ bool wmi_backlight_set_devstate;
bool wmi_force_als_set;
int wapf;
/*
--
2.20.1
[PATCH AUTOSEL 4.19 25/34] platform/x86: intel-vbtn: Report switch events when event wakes device
From: Mathew King
[ Upstream commit cb1921b17adbe6509538098ac431033378cd7165 ]
When a switch event, such as tablet mode/laptop mode or docked/undocked,
wakes a device make sure that the value of the swich is reported.
Without when a device is put in tablet mode from laptop mode when it is
suspended or vice versa the device will wake up but mode will be
incorrect.
Tested by suspending a device in laptop mode and putting it in tablet
mode, the device resumes and is in tablet mode. When suspending the
device in tablet mode and putting it in laptop mode the device resumes
and is in laptop mode.
Signed-off-by: Mathew King
Reviewed-by: Jett Rink
Reviewed-by: Mario Limonciello
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
---
drivers/platform/x86/intel-vbtn.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/intel-vbtn.c
b/drivers/platform/x86/intel-vbtn.c
index 06cd7e818ed5..a0d0cecff55f 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -76,12 +76,24 @@ static void notify_handler(acpi_handle handle, u32 event,
void *context)
struct platform_device *device = context;
struct intel_vbtn_priv *priv = dev_get_drvdata(>dev);
unsigned int val = !(event & 1); /* Even=press, Odd=release */
- const struct key_entry *ke_rel;
+ const struct key_entry *ke, *ke_rel;
bool autorelease;
if (priv->wakeup_mode) {
- if (sparse_keymap_entry_from_scancode(priv->input_dev, event)) {
+ ke = sparse_keymap_entry_from_scancode(priv->input_dev, event);
+ if (ke) {
pm_wakeup_hard_event(>dev);
+
+ /*
+* Switch events like tablet mode will wake the device
+* and report the new switch position to the input
+* subsystem.
+*/
+ if (ke->type == KE_SW)
+ sparse_keymap_report_event(priv->input_dev,
+ event,
+ val,
+ 0);
return;
}
goto out_unknown;
--
2.20.1
[PATCH AUTOSEL 4.14 08/21] drm/mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable()
From: Hsin-Yi Wang
[ Upstream commit 2458d9d6d94be982b917e93c61a89b4426f32e31 ]
mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which
needs ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is
called, ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called
after last irq, it will timeout with this message: "vblank wait timed out
on crtc 0". This happens sometimes when turning off the screen.
In drm_atomic_helper.c#disable_outputs(),
the calling sequence when turning off the screen is:
1. mtk_dsi_encoder_disable()
--> mtk_output_dsi_disable()
--> mtk_dsi_stop(); /* sometimes make vblank timeout in
atomic_disable */
--> mtk_dsi_poweroff();
2. mtk_drm_crtc_atomic_disable()
--> drm_crtc_wait_one_vblank();
...
--> mtk_dsi_ddp_stop()
--> mtk_dsi_poweroff();
mtk_dsi_poweroff() has reference count design, change to make
mtk_dsi_stop() called in mtk_dsi_poweroff() when refcount is 0.
Fixes: 0707632b5bac ("drm/mediatek: update DSI sub driver flow for sending
commands to panel")
Signed-off-by: Hsin-Yi Wang
Signed-off-by: CK Hu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 413313f19c36..c1b8caad65e6 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -631,6 +631,15 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
if (--dsi->refcount != 0)
return;
+ /*
+* mtk_dsi_stop() and mtk_dsi_start() is asymmetric, since
+* mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(),
+* which needs irq for vblank, and mtk_dsi_stop() will disable irq.
+* mtk_dsi_start() needs to be called in mtk_output_dsi_enable(),
+* after dsi is fully set.
+*/
+ mtk_dsi_stop(dsi);
+
if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
if (dsi->panel) {
if (drm_panel_unprepare(dsi->panel)) {
@@ -697,7 +706,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
}
}
- mtk_dsi_stop(dsi);
mtk_dsi_poweroff(dsi);
dsi->enabled = false;
--
2.20.1
[PATCH AUTOSEL 4.14 18/21] scripts/decode_stacktrace.sh: prefix addr2line with $CROSS_COMPILE
From: Manuel Traut
[ Upstream commit c04e32e911653442fc834be6e92e072aeebe01a1 ]
At least for ARM64 kernels compiled with the crosstoolchain from
Debian/stretch or with the toolchain from kernel.org the line number is
not decoded correctly by 'decode_stacktrace.sh':
$ echo "[ 136.513051] f1+0x0/0xc [kcrash]" | \
CROSS_COMPILE=/opt/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux- \
./scripts/decode_stacktrace.sh /scratch/linux-arm64/vmlinux \
/scratch/linux-arm64 \
/nfs/debian/lib/modules/4.20.0-devel
[ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:68) kcrash
If addr2line from the toolchain is used the decoded line number is correct:
[ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:57) kcrash
Link: http://lkml.kernel.org/r/20190527083425.3763-1-ma...@linutronix.de
Signed-off-by: Manuel Traut
Acked-by: Konstantin Khlebnikov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
scripts/decode_stacktrace.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
index 98a7d63a723e..c4a9ddb174bc 100755
--- a/scripts/decode_stacktrace.sh
+++ b/scripts/decode_stacktrace.sh
@@ -66,7 +66,7 @@ parse_symbol() {
if [[ "${cache[$module,$address]+isset}" == "isset" ]]; then
local code=${cache[$module,$address]}
else
- local code=$(addr2line -i -e "$objfile" "$address")
+ local code=$(${CROSS_COMPILE}addr2line -i -e "$objfile"
"$address")
cache[$module,$address]=$code
fi
--
2.20.1
[PATCH AUTOSEL 4.14 04/21] ASoC: core: lock client_mutex while removing link components
From: Ranjani Sridharan
[ Upstream commit 34ac3c3eb8f0c07252ceddf0a22dd240e5c91ccb ]
Removing link components results in topology unloading. So,
acquire the client_mutex before removing components in
soc_remove_link_components. This will prevent the lockdep warning
seen when dai links are removed during topology removal.
Signed-off-by: Ranjani Sridharan
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/soc-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 42c2a3065b77..eb23c237b622 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1258,12 +1258,14 @@ static void soc_remove_link_components(struct
snd_soc_card *card,
struct snd_soc_component *component;
struct snd_soc_rtdcom_list *rtdcom;
+ mutex_lock(_mutex);
for_each_rtdcom(rtd, rtdcom) {
component = rtdcom->component;
if (component->driver->remove_order == order)
soc_remove_component(component);
}
+ mutex_unlock(_mutex);
}
static void soc_remove_dai_links(struct snd_soc_card *card)
--
2.20.1
[PATCH AUTOSEL 4.14 14/21] SoC: rt274: Fix internal jack assignment in set_jack callback
From: Amadeusz Sławiński
[ Upstream commit 04268bf2757a125616b6c2140e6250f43b7b737a ]
When we call snd_soc_component_set_jack(component, NULL, NULL) we should
set rt274->jack to passed jack, so when interrupt is triggered it calls
snd_soc_jack_report(rt274->jack, ...) with proper value.
This fixes problem in machine where in register, we call
snd_soc_register(component, , NULL), which just calls
rt274_mic_detect via callback.
Now when machine driver is removed "headset" will be gone, so we
need to tell codec driver that it's gone with:
snd_soc_register(component, NULL, NULL), but we also need to be able
to handle NULL jack argument here gracefully.
If we don't set it to NULL, next time the rt274_irq runs it will call
snd_soc_jack_report with first argument being invalid pointer and there
will be Oops.
Signed-off-by: Amadeusz Sławiński
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/rt274.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/rt274.c b/sound/soc/codecs/rt274.c
index cd048df76232..43086ac9ffec 100644
--- a/sound/soc/codecs/rt274.c
+++ b/sound/soc/codecs/rt274.c
@@ -398,6 +398,8 @@ static int rt274_mic_detect(struct snd_soc_codec *codec,
{
struct rt274_priv *rt274 = snd_soc_codec_get_drvdata(codec);
+ rt274->jack = jack;
+
if (jack == NULL) {
/* Disable jack detection */
regmap_update_bits(rt274->regmap, RT274_EAPD_GPIO_IRQ_CTRL,
@@ -405,7 +407,6 @@ static int rt274_mic_detect(struct snd_soc_codec *codec,
return 0;
}
- rt274->jack = jack;
regmap_update_bits(rt274->regmap, RT274_EAPD_GPIO_IRQ_CTRL,
RT274_IRQ_EN, RT274_IRQ_EN);
--
2.20.1
[PATCH AUTOSEL 4.14 01/21] ASoC : cs4265 : readable register too low
From: Matt Flax
[ Upstream commit f3df05c805983427319eddc2411a2105ee1757cf ]
The cs4265_readable_register function stopped short of the maximum
register.
An example bug is taken from :
https://github.com/Audio-Injector/Ultra/issues/25
Where alsactl store fails with :
Cannot read control '2,0,0,C Data Buffer,0': Input/output error
This patch fixes the bug by setting the cs4265 to have readable
registers up to the maximum hardware register CS4265_MAX_REGISTER.
Signed-off-by: Matt Flax
Reviewed-by: Charles Keepax
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/cs4265.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/cs4265.c b/sound/soc/codecs/cs4265.c
index 6e8eb1f5a041..bed64723e5d9 100644
--- a/sound/soc/codecs/cs4265.c
+++ b/sound/soc/codecs/cs4265.c
@@ -60,7 +60,7 @@ static const struct reg_default cs4265_reg_defaults[] = {
static bool cs4265_readable_register(struct device *dev, unsigned int reg)
{
switch (reg) {
- case CS4265_CHIP_ID ... CS4265_SPDIF_CTL2:
+ case CS4265_CHIP_ID ... CS4265_MAX_REGISTER:
return true;
default:
return false;
--
2.20.1
[PATCH AUTOSEL 4.14 19/21] mm/mlock.c: change count_mm_mlocked_page_nr return type
From: swkhack
[ Upstream commit 0874bb49bb21bf24deda853e8bf61b8325e24bcb ]
On a 64-bit machine the value of "vma->vm_end - vma->vm_start" may be
negative when using 32 bit ints and the "count >> PAGE_SHIFT"'s result
will be wrong. So change the local variable and return value to
unsigned long to fix the problem.
Link: http://lkml.kernel.org/r/20190513023701.83056-1-swkh...@gmail.com
Fixes: 0cf2f6f6dc60 ("mm: mlock: check against vma for actual mlock() size")
Signed-off-by: swkhack
Acked-by: Michal Hocko
Reviewed-by: Andrew Morton
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
mm/mlock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/mlock.c b/mm/mlock.c
index 46af369c13e5..1f9ee86672e8 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -629,11 +629,11 @@ static int apply_vma_lock_flags(unsigned long start,
size_t len,
* is also counted.
* Return value: previously mlocked page counts
*/
-static int count_mm_mlocked_page_nr(struct mm_struct *mm,
+static unsigned long count_mm_mlocked_page_nr(struct mm_struct *mm,
unsigned long start, size_t len)
{
struct vm_area_struct *vma;
- int count = 0;
+ unsigned long count = 0;
if (mm == NULL)
mm = current->mm;
--
2.20.1
Re: [PATCH] docs: zh_CN: submitting-drivers.rst: Remove a duplicated Documentation/
Thanks for catching. Reviewed-by: Alex Shi 在 2019/6/23 上午1:47, Mauro Carvalho Chehab 写道: Somehow, this file ended with Documentation/ twice. Signed-off-by: Mauro Carvalho Chehab --- Documentation/translations/zh_CN/process/submitting-drivers.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/translations/zh_CN/process/submitting-drivers.rst b/Documentation/translations/zh_CN/process/submitting-drivers.rst index 72c6cd935821..72f4f45c98de 100644 --- a/Documentation/translations/zh_CN/process/submitting-drivers.rst +++ b/Documentation/translations/zh_CN/process/submitting-drivers.rst @@ -22,7 +22,7 @@ 兴趣的是显卡驱动程序，你也许应该访问 XFree86 项目(http://www.xfree86.org/) 和／或 X.org 项目 (http://x.org)。 -另请参阅 Documentation/Documentation/translations/zh_CN/process/submitting-patches.rst 文档。 +另请参阅 Documentation/translations/zh_CN/process/submitting-patches.rst 文档。 分配设备号
[PATCH AUTOSEL 4.14 16/21] platform/x86: mlx-platform: Fix parent device in i2c-mux-reg device registration
From: Vadim Pasternak
[ Upstream commit 160da20b254dd4bfc5828f12c208fa831ad4be6c ]
Fix the issue found while running kernel with the option
CONFIG_DEBUG_TEST_DRIVER_REMOVE.
Driver 'mlx-platform' registers 'i2c_mlxcpld' device and then registers
few underlying 'i2c-mux-reg' devices:
priv->pdev_i2c = platform_device_register_simple("i2c_mlxcpld", nr,
NULL, 0);
...
for (i = 0; i < ARRAY_SIZE(mlxplat_mux_data); i++) {
priv->pdev_mux[i] = platform_device_register_resndata(
_dev->dev,
"i2c-mux-reg", i, NULL,
0, _mux_data[i],
sizeof(mlxplat_mux_data[i]));
But actual parent of "i2c-mux-reg" device is priv->pdev_i2c->dev and
not mlxplat_dev->dev.
Patch fixes parent device parameter in a call to
platform_device_register_resndata() for "i2c-mux-reg".
It solves the race during initialization flow while 'i2c_mlxcpld.1' is
removing after probe, while 'i2c-mux-reg.0' is still in probing flow:
'i2c_mlxcpld.1' flow: probe -> remove -> probe.
'i2c-mux-reg.0' flow: probe -> ...
[ 12:621096] Registering platform device 'i2c_mlxcpld.1'. Parent at platform
[ 12:621117] device: 'i2c_mlxcpld.1': device_add
[ 12:621155] bus: 'platform': add device i2c_mlxcpld.1
[ 12:621384] Registering platform device 'i2c-mux-reg.0'. Parent at mlxplat
[ 12:621395] device: 'i2c-mux-reg.0': device_add
[ 12:621425] bus: 'platform': add device i2c-mux-reg.0
[ 12:621806] Registering platform device 'i2c-mux-reg.1'. Parent at mlxplat
[ 12:621828] device: 'i2c-mux-reg.1': device_add
[ 12:621892] bus: 'platform': add device i2c-mux-reg.1
[ 12:621906] bus: 'platform': add driver i2c_mlxcpld
[ 12:621996] bus: 'platform': driver_probe_device: matched device
i2c_mlxcpld.1 with driver i2c_mlxcpld
[ 12:622003] bus: 'platform': really_probe: probing driver i2c_mlxcpld with
device i2c_mlxcpld.1
[ 12:622100] i2c_mlxcpld i2c_mlxcpld.1: no default pinctrl state
[ 12:622293] device: 'i2c-1': device_add
[ 12:627280] bus: 'i2c': add device i2c-1
[ 12:627692] device: 'i2c-1': device_add
[ 12.629639] bus: 'platform': add driver i2c-mux-reg
[ 12.629718] bus: 'platform': driver_probe_device: matched device
i2c-mux-reg.0 with driver i2c-mux-reg
[ 12.629723] bus: 'platform': really_probe: probing driver i2c-mux-reg with
device i2c-mux-reg.0
[ 12.629818] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
[ 12.629981] platform i2c-mux-reg.0: Driver i2c-mux-reg requests probe
deferral
[ 12.629986] platform i2c-mux-reg.0: Added to deferred list
[ 12.629992] bus: 'platform': driver_probe_device: matched device
i2c-mux-reg.1 with driver i2c-mux-reg
[ 12.629997] bus: 'platform': really_probe: probing driver i2c-mux-reg with
device i2c-mux-reg.1
[ 12.630091] i2c-mux-reg i2c-mux-reg.1: no default pinctrl state
[ 12.630247] platform i2c-mux-reg.1: Driver i2c-mux-reg requests probe
deferral
[ 12.630252] platform i2c-mux-reg.1: Added to deferred list
[ 12.640892] devices_kset: Moving i2c-mux-reg.0 to end of list
[ 12.640900] platform i2c-mux-reg.0: Retrying from deferred list
[ 12.640911] bus: 'platform': driver_probe_device: matched device
i2c-mux-reg.0 with driver i2c-mux-reg
[ 12.640919] bus: 'platform': really_probe: probing driver i2c-mux-reg with
device i2c-mux-reg.0
[ 12.640999] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
[ 12.641177] platform i2c-mux-reg.0: Driver i2c-mux-reg requests probe
deferral
[ 12.641187] platform i2c-mux-reg.0: Added to deferred list
[ 12.641198] devices_kset: Moving i2c-mux-reg.1 to end of list
[ 12.641219] platform i2c-mux-reg.1: Retrying from deferred list
[ 12.641237] bus: 'platform': driver_probe_device: matched device
i2c-mux-reg.1 with driver i2c-mux-reg
[ 12.641247] bus: 'platform': really_probe: probing driver i2c-mux-reg with
device i2c-mux-reg.1
[ 12.641331] i2c-mux-reg i2c-mux-reg.1: no default pinctrl state
[ 12.641465] platform i2c-mux-reg.1: Driver i2c-mux-reg requests probe
deferral
[ 12.641469] platform i2c-mux-reg.1: Added to deferred list
[ 12.646427] device: 'i2c-1': device_add
[ 12.646647] bus: 'i2c': add device i2c-1
[ 12.647104] device: 'i2c-1': device_add
[ 12.669231] devices_kset: Moving i2c-mux-reg.0 to end of list
[ 12.669240] platform i2c-mux-reg.0: Retrying from deferred list
[ 12.669258] bus: 'platform': driver_probe_device: matched device
i2c-mux-reg.0 with driver i2c-mux-reg
[ 12.669263] bus: 'platform': really_probe: probing driver i2c-mux-reg with
device i2c-mux-reg.0
[ 12.669343] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
[ 12.669585] device: 'i2c-2': device_add
[ 12.669795] bus: 'i2c': add device i2c-2
[ 12.670201] device: 'i2c-2': device_add
[ 12.671427] i2c i2c-1: Added
[PATCH AUTOSEL 4.4 3/6] ASoC: max98090: remove 24-bit format support if RJ is 0
From: Yu-Hsuan Hsu
[ Upstream commit 5628c8979642a076f91ee86c3bae5ad251639af0 ]
The supported formats are S16_LE and S24_LE now. However, by datasheet
of max98090, S24_LE is only supported when it is in the right justified
mode. We should remove 24-bit format if it is not in that mode to avoid
triggering error.
Signed-off-by: Yu-Hsuan Hsu
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/max98090.c | 16
1 file changed, 16 insertions(+)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index 3e65dc74eb33..e7aef841f87d 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -1924,6 +1924,21 @@ static int max98090_configure_dmic(struct max98090_priv
*max98090,
return 0;
}
+static int max98090_dai_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_component *component = dai->component;
+ struct max98090_priv *max98090 =
snd_soc_component_get_drvdata(component);
+ unsigned int fmt = max98090->dai_fmt;
+
+ /* Remove 24-bit format support if it is not in right justified mode. */
+ if ((fmt & SND_SOC_DAIFMT_FORMAT_MASK) != SND_SOC_DAIFMT_RIGHT_J) {
+ substream->runtime->hw.formats = SNDRV_PCM_FMTBIT_S16_LE;
+ snd_pcm_hw_constraint_msbits(substream->runtime, 0, 16, 16);
+ }
+ return 0;
+}
+
static int max98090_dai_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
@@ -2331,6 +2346,7 @@ EXPORT_SYMBOL_GPL(max98090_mic_detect);
#define MAX98090_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE)
static const struct snd_soc_dai_ops max98090_dai_ops = {
+ .startup = max98090_dai_startup,
.set_sysclk = max98090_dai_set_sysclk,
.set_fmt = max98090_dai_set_fmt,
.set_tdm_slot = max98090_set_tdm_slot,
--
2.20.1
[PATCH AUTOSEL 4.9 09/11] scsi: hpsa: correct ioaccel2 chaining
From: Don Brace
[ Upstream commit 625d7d3518875c4d303c652a198feaa13d9f52d9 ]
- set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_LAST_SG for
the last s/g element.
- set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_CHAIN when
chaining.
Reviewed-by: Bader Ali - Saleh
Reviewed-by: Scott Teel
Reviewed-by: Matt Perricone
Signed-off-by: Don Brace
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/hpsa.c | 7 ++-
drivers/scsi/hpsa_cmd.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 0b8db8a74d50..9f98c7211ec2 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -4815,7 +4815,7 @@ static int hpsa_scsi_ioaccel2_queue_command(struct
ctlr_info *h,
curr_sg->reserved[0] = 0;
curr_sg->reserved[1] = 0;
curr_sg->reserved[2] = 0;
- curr_sg->chain_indicator = 0x80;
+ curr_sg->chain_indicator = IOACCEL2_CHAIN;
curr_sg = h->ioaccel2_cmd_sg_list[c->cmdindex];
}
@@ -4832,6 +4832,11 @@ static int hpsa_scsi_ioaccel2_queue_command(struct
ctlr_info *h,
curr_sg++;
}
+ /*
+* Set the last s/g element bit
+*/
+ (curr_sg - 1)->chain_indicator = IOACCEL2_LAST_SG;
+
switch (cmd->sc_data_direction) {
case DMA_TO_DEVICE:
cp->direction &= ~IOACCEL2_DIRECTION_MASK;
diff --git a/drivers/scsi/hpsa_cmd.h b/drivers/scsi/hpsa_cmd.h
index 5961705eef76..39bcbec93c60 100644
--- a/drivers/scsi/hpsa_cmd.h
+++ b/drivers/scsi/hpsa_cmd.h
@@ -516,6 +516,7 @@ struct ioaccel2_sg_element {
u8 reserved[3];
u8 chain_indicator;
#define IOACCEL2_CHAIN 0x80
+#define IOACCEL2_LAST_SG 0x40
};
/*
--
2.20.1
[PATCH AUTOSEL 4.4 6/6] scsi: hpsa: correct ioaccel2 chaining
From: Don Brace
[ Upstream commit 625d7d3518875c4d303c652a198feaa13d9f52d9 ]
- set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_LAST_SG for
the last s/g element.
- set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_CHAIN when
chaining.
Reviewed-by: Bader Ali - Saleh
Reviewed-by: Scott Teel
Reviewed-by: Matt Perricone
Signed-off-by: Don Brace
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/hpsa.c | 7 ++-
drivers/scsi/hpsa_cmd.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 910b795fc5eb..e0952882e132 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -4562,7 +4562,7 @@ static int hpsa_scsi_ioaccel2_queue_command(struct
ctlr_info *h,
curr_sg->reserved[0] = 0;
curr_sg->reserved[1] = 0;
curr_sg->reserved[2] = 0;
- curr_sg->chain_indicator = 0x80;
+ curr_sg->chain_indicator = IOACCEL2_CHAIN;
curr_sg = h->ioaccel2_cmd_sg_list[c->cmdindex];
}
@@ -4579,6 +4579,11 @@ static int hpsa_scsi_ioaccel2_queue_command(struct
ctlr_info *h,
curr_sg++;
}
+ /*
+* Set the last s/g element bit
+*/
+ (curr_sg - 1)->chain_indicator = IOACCEL2_LAST_SG;
+
switch (cmd->sc_data_direction) {
case DMA_TO_DEVICE:
cp->direction &= ~IOACCEL2_DIRECTION_MASK;
diff --git a/drivers/scsi/hpsa_cmd.h b/drivers/scsi/hpsa_cmd.h
index 26488e2a7f02..7ffde12d57d4 100644
--- a/drivers/scsi/hpsa_cmd.h
+++ b/drivers/scsi/hpsa_cmd.h
@@ -513,6 +513,7 @@ struct ioaccel2_sg_element {
u8 reserved[3];
u8 chain_indicator;
#define IOACCEL2_CHAIN 0x80
+#define IOACCEL2_LAST_SG 0x40
};
/*
--
2.20.1
[PATCH AUTOSEL 4.9 10/11] scripts/decode_stacktrace.sh: prefix addr2line with $CROSS_COMPILE
From: Manuel Traut
[ Upstream commit c04e32e911653442fc834be6e92e072aeebe01a1 ]
At least for ARM64 kernels compiled with the crosstoolchain from
Debian/stretch or with the toolchain from kernel.org the line number is
not decoded correctly by 'decode_stacktrace.sh':
$ echo "[ 136.513051] f1+0x0/0xc [kcrash]" | \
CROSS_COMPILE=/opt/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux- \
./scripts/decode_stacktrace.sh /scratch/linux-arm64/vmlinux \
/scratch/linux-arm64 \
/nfs/debian/lib/modules/4.20.0-devel
[ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:68) kcrash
If addr2line from the toolchain is used the decoded line number is correct:
[ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:57) kcrash
Link: http://lkml.kernel.org/r/20190527083425.3763-1-ma...@linutronix.de
Signed-off-by: Manuel Traut
Acked-by: Konstantin Khlebnikov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
scripts/decode_stacktrace.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
index edde8250195c..381acfc4c59d 100755
--- a/scripts/decode_stacktrace.sh
+++ b/scripts/decode_stacktrace.sh
@@ -65,7 +65,7 @@ parse_symbol() {
if [[ "${cache[$module,$address]+isset}" == "isset" ]]; then
local code=${cache[$module,$address]}
else
- local code=$(addr2line -i -e "$objfile" "$address")
+ local code=$(${CROSS_COMPILE}addr2line -i -e "$objfile"
"$address")
cache[$module,$address]=$code
fi
--
2.20.1
[PATCH AUTOSEL 4.9 11/11] mm/mlock.c: change count_mm_mlocked_page_nr return type
From: swkhack
[ Upstream commit 0874bb49bb21bf24deda853e8bf61b8325e24bcb ]
On a 64-bit machine the value of "vma->vm_end - vma->vm_start" may be
negative when using 32 bit ints and the "count >> PAGE_SHIFT"'s result
will be wrong. So change the local variable and return value to
unsigned long to fix the problem.
Link: http://lkml.kernel.org/r/20190513023701.83056-1-swkh...@gmail.com
Fixes: 0cf2f6f6dc60 ("mm: mlock: check against vma for actual mlock() size")
Signed-off-by: swkhack
Acked-by: Michal Hocko
Reviewed-by: Andrew Morton
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
mm/mlock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/mlock.c b/mm/mlock.c
index f0505692a5f4..3e7fe404bfb8 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -630,11 +630,11 @@ static int apply_vma_lock_flags(unsigned long start,
size_t len,
* is also counted.
* Return value: previously mlocked page counts
*/
-static int count_mm_mlocked_page_nr(struct mm_struct *mm,
+static unsigned long count_mm_mlocked_page_nr(struct mm_struct *mm,
unsigned long start, size_t len)
{
struct vm_area_struct *vma;
- int count = 0;
+ unsigned long count = 0;
if (mm == NULL)
mm = current->mm;
--
2.20.1
[PATCH AUTOSEL 4.4 4/6] usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i]
From: Young Xiao <92siuy...@gmail.com>
[ Upstream commit 62fd0e0a24abeebe2c19fce49dd5716d9b62042d ]
There is no deallocation of fusb300->ep[i] elements, allocated at
fusb300_probe.
The patch adds deallocation of fusb300->ep array elements.
Signed-off-by: Young Xiao <92siuy...@gmail.com>
Signed-off-by: Felipe Balbi
Signed-off-by: Sasha Levin
---
drivers/usb/gadget/udc/fusb300_udc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/gadget/udc/fusb300_udc.c
b/drivers/usb/gadget/udc/fusb300_udc.c
index 948845c90e47..351012c498c5 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -1345,12 +1345,15 @@ static const struct usb_gadget_ops fusb300_gadget_ops =
{
static int fusb300_remove(struct platform_device *pdev)
{
struct fusb300 *fusb300 = platform_get_drvdata(pdev);
+ int i;
usb_del_gadget_udc(>gadget);
iounmap(fusb300->reg);
free_irq(platform_get_irq(pdev, 0), fusb300);
fusb300_free_request(>ep[0]->ep, fusb300->ep0_req);
+ for (i = 0; i < FUSB300_MAX_NUM_EP; i++)
+ kfree(fusb300->ep[i]);
kfree(fusb300);
return 0;
@@ -1494,6 +1497,8 @@ static int fusb300_probe(struct platform_device *pdev)
if (fusb300->ep0_req)
fusb300_free_request(>ep[0]->ep,
fusb300->ep0_req);
+ for (i = 0; i < FUSB300_MAX_NUM_EP; i++)
+ kfree(fusb300->ep[i]);
kfree(fusb300);
}
if (reg)
--
2.20.1
[PATCH AUTOSEL 4.4 2/6] spi: bitbang: Fix NULL pointer dereference in spi_unregister_master
From: YueHaibing
[ Upstream commit 5caaf29af5ca82d5da8bc1d0ad07d9e664ccf1d8 ]
If spi_register_master fails in spi_bitbang_start
because device_add failure, We should return the
error code other than 0, otherwise calling
spi_bitbang_stop may trigger NULL pointer dereference
like this:
BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0
Read of size 8 at addr by task syz-executor.0/3661
CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
04/01/2014
Call Trace:
dump_stack+0xa9/0x10e
? __list_del_entry_valid+0x45/0xd0
? __list_del_entry_valid+0x45/0xd0
__kasan_report+0x171/0x18d
? __list_del_entry_valid+0x45/0xd0
kasan_report+0xe/0x20
__list_del_entry_valid+0x45/0xd0
spi_unregister_controller+0x99/0x1b0
spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp]
? 0xc1128000
? klist_next+0x131/0x1e0
? driver_detach+0x40/0x40 [parport]
port_check+0x3b/0x50 [parport]
bus_for_each_dev+0x115/0x180
? subsys_dev_iter_exit+0x20/0x20
__parport_register_driver+0x1f0/0x210 [parport]
? 0xc115
do_one_initcall+0xb9/0x3b5
? perf_trace_initcall_level+0x270/0x270
? kasan_unpoison_shadow+0x30/0x40
? kasan_unpoison_shadow+0x30/0x40
do_init_module+0xe0/0x330
load_module+0x38eb/0x4270
? module_frob_arch_sections+0x20/0x20
? kernel_read_file+0x188/0x3f0
? find_held_lock+0x6d/0xd0
? fput_many+0x1a/0xe0
? __do_sys_finit_module+0x162/0x190
__do_sys_finit_module+0x162/0x190
? __ia32_sys_init_module+0x40/0x40
? __mutex_unlock_slowpath+0xb4/0x3f0
? wait_for_completion+0x240/0x240
? vfs_write+0x160/0x2a0
? lockdep_hardirqs_off+0xb5/0x100
? mark_held_locks+0x1a/0x90
? do_syscall_64+0x14/0x2a0
do_syscall_64+0x72/0x2a0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Reported-by: Hulk Robot
Fixes: 702a4879ec33 ("spi: bitbang: Let spi_bitbang_start() take a reference to
master")
Signed-off-by: YueHaibing
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Axel Lin
Reviewed-by: Mukesh Ojha
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi-bitbang.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-bitbang.c b/drivers/spi/spi-bitbang.c
index 3aa9e6e3dac8..4ef54436b9d4 100644
--- a/drivers/spi/spi-bitbang.c
+++ b/drivers/spi/spi-bitbang.c
@@ -392,7 +392,7 @@ int spi_bitbang_start(struct spi_bitbang *bitbang)
if (ret)
spi_master_put(master);
- return 0;
+ return ret;
}
EXPORT_SYMBOL_GPL(spi_bitbang_start);
--
2.20.1
[PATCH AUTOSEL 4.4 1/6] ASoC : cs4265 : readable register too low
From: Matt Flax
[ Upstream commit f3df05c805983427319eddc2411a2105ee1757cf ]
The cs4265_readable_register function stopped short of the maximum
register.
An example bug is taken from :
https://github.com/Audio-Injector/Ultra/issues/25
Where alsactl store fails with :
Cannot read control '2,0,0,C Data Buffer,0': Input/output error
This patch fixes the bug by setting the cs4265 to have readable
registers up to the maximum hardware register CS4265_MAX_REGISTER.
Signed-off-by: Matt Flax
Reviewed-by: Charles Keepax
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/cs4265.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/cs4265.c b/sound/soc/codecs/cs4265.c
index 93b02be3a90e..6edec2387861 100644
--- a/sound/soc/codecs/cs4265.c
+++ b/sound/soc/codecs/cs4265.c
@@ -60,7 +60,7 @@ static const struct reg_default cs4265_reg_defaults[] = {
static bool cs4265_readable_register(struct device *dev, unsigned int reg)
{
switch (reg) {
- case CS4265_CHIP_ID ... CS4265_SPDIF_CTL2:
+ case CS4265_CHIP_ID ... CS4265_MAX_REGISTER:
return true;
default:
return false;
--
2.20.1
[PATCH AUTOSEL 4.4 5/6] usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC
From: Alexandre Belloni [ Upstream commit fbc318afadd6e7ae2252d6158cf7d0c5a2132f7d ] Gadget drivers may queue request in interrupt context. This would lead to a descriptor allocation in that context. In that case we would hit BUG_ON(in_interrupt()) in __get_vm_area_node. Also remove the unnecessary cast. Acked-by: Sylvain Lemieux Tested-by: James Grant Signed-off-by: Alexandre Belloni Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin --- drivers/usb/gadget/udc/lpc32xx_udc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c b/drivers/usb/gadget/udc/lpc32xx_udc.c index 00b5006baf15..90d24f62bd81 100644 --- a/drivers/usb/gadget/udc/lpc32xx_udc.c +++ b/drivers/usb/gadget/udc/lpc32xx_udc.c @@ -964,8 +964,7 @@ static struct lpc32xx_usbd_dd_gad *udc_dd_alloc(struct lpc32xx_udc *udc) dma_addr_t dma; struct lpc32xx_usbd_dd_gad *dd; - dd = (struct lpc32xx_usbd_dd_gad *) dma_pool_alloc( - udc->dd_cache, (GFP_KERNEL | GFP_DMA), ); + dd = dma_pool_alloc(udc->dd_cache, GFP_ATOMIC | GFP_DMA, ); if (dd) dd->this_dma = dma; -- 2.20.1
[PATCH AUTOSEL 4.9 08/11] usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC
From: Alexandre Belloni [ Upstream commit fbc318afadd6e7ae2252d6158cf7d0c5a2132f7d ] Gadget drivers may queue request in interrupt context. This would lead to a descriptor allocation in that context. In that case we would hit BUG_ON(in_interrupt()) in __get_vm_area_node. Also remove the unnecessary cast. Acked-by: Sylvain Lemieux Tested-by: James Grant Signed-off-by: Alexandre Belloni Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin --- drivers/usb/gadget/udc/lpc32xx_udc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c b/drivers/usb/gadget/udc/lpc32xx_udc.c index 8f32b5ee7734..6df1aded4503 100644 --- a/drivers/usb/gadget/udc/lpc32xx_udc.c +++ b/drivers/usb/gadget/udc/lpc32xx_udc.c @@ -935,8 +935,7 @@ static struct lpc32xx_usbd_dd_gad *udc_dd_alloc(struct lpc32xx_udc *udc) dma_addr_t dma; struct lpc32xx_usbd_dd_gad *dd; - dd = (struct lpc32xx_usbd_dd_gad *) dma_pool_alloc( - udc->dd_cache, (GFP_KERNEL | GFP_DMA), ); + dd = dma_pool_alloc(udc->dd_cache, GFP_ATOMIC | GFP_DMA, ); if (dd) dd->this_dma = dma; -- 2.20.1
[PATCH AUTOSEL 4.9 01/11] ASoC : cs4265 : readable register too low
From: Matt Flax
[ Upstream commit f3df05c805983427319eddc2411a2105ee1757cf ]
The cs4265_readable_register function stopped short of the maximum
register.
An example bug is taken from :
https://github.com/Audio-Injector/Ultra/issues/25
Where alsactl store fails with :
Cannot read control '2,0,0,C Data Buffer,0': Input/output error
This patch fixes the bug by setting the cs4265 to have readable
registers up to the maximum hardware register CS4265_MAX_REGISTER.
Signed-off-by: Matt Flax
Reviewed-by: Charles Keepax
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/cs4265.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/cs4265.c b/sound/soc/codecs/cs4265.c
index 6e8eb1f5a041..bed64723e5d9 100644
--- a/sound/soc/codecs/cs4265.c
+++ b/sound/soc/codecs/cs4265.c
@@ -60,7 +60,7 @@ static const struct reg_default cs4265_reg_defaults[] = {
static bool cs4265_readable_register(struct device *dev, unsigned int reg)
{
switch (reg) {
- case CS4265_CHIP_ID ... CS4265_SPDIF_CTL2:
+ case CS4265_CHIP_ID ... CS4265_MAX_REGISTER:
return true;
default:
return false;
--
2.20.1
[PATCH AUTOSEL 4.9 04/11] ASoC: sun4i-codec: fix first delay on Speaker
From: Georgii Staroselskii
[ Upstream commit 1f2675f6655838aaf910f911fd0abc821e3ff3df ]
Allwinner DAC seems to have a delay in the Speaker audio routing. When
playing a sound for the first time, the sound gets chopped. On a second
play the sound is played correctly. After some time (~5s) the issue gets
back.
This commit seems to be fixing the same issue as bf14da7 but
for another codepath.
This is the DTS that was used to debug the problem.
{
allwinner,pa-gpios = <_pio 0 11 GPIO_ACTIVE_HIGH>; /* PL11 */
allwinner,audio-routing =
"Speaker", "LINEOUT";
status = "okay";
}
Signed-off-by: Georgii Staroselskii
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/sunxi/sun4i-codec.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 56ed9472e89f..6099adea68c6 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -747,6 +747,15 @@ static int sun4i_codec_spk_event(struct
snd_soc_dapm_widget *w,
gpiod_set_value_cansleep(scodec->gpio_pa,
!!SND_SOC_DAPM_EVENT_ON(event));
+ if (SND_SOC_DAPM_EVENT_ON(event)) {
+ /*
+* Need a delay to wait for DAC to push the data. 700ms seems
+* to be the best compromise not to feel this delay while
+* playing a sound.
+*/
+ msleep(700);
+ }
+
return 0;
}
--
2.20.1
[PATCH AUTOSEL 4.9 07/11] usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i]
From: Young Xiao <92siuy...@gmail.com>
[ Upstream commit 62fd0e0a24abeebe2c19fce49dd5716d9b62042d ]
There is no deallocation of fusb300->ep[i] elements, allocated at
fusb300_probe.
The patch adds deallocation of fusb300->ep array elements.
Signed-off-by: Young Xiao <92siuy...@gmail.com>
Signed-off-by: Felipe Balbi
Signed-off-by: Sasha Levin
---
drivers/usb/gadget/udc/fusb300_udc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/gadget/udc/fusb300_udc.c
b/drivers/usb/gadget/udc/fusb300_udc.c
index 948845c90e47..351012c498c5 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -1345,12 +1345,15 @@ static const struct usb_gadget_ops fusb300_gadget_ops =
{
static int fusb300_remove(struct platform_device *pdev)
{
struct fusb300 *fusb300 = platform_get_drvdata(pdev);
+ int i;
usb_del_gadget_udc(>gadget);
iounmap(fusb300->reg);
free_irq(platform_get_irq(pdev, 0), fusb300);
fusb300_free_request(>ep[0]->ep, fusb300->ep0_req);
+ for (i = 0; i < FUSB300_MAX_NUM_EP; i++)
+ kfree(fusb300->ep[i]);
kfree(fusb300);
return 0;
@@ -1494,6 +1497,8 @@ static int fusb300_probe(struct platform_device *pdev)
if (fusb300->ep0_req)
fusb300_free_request(>ep[0]->ep,
fusb300->ep0_req);
+ for (i = 0; i < FUSB300_MAX_NUM_EP; i++)
+ kfree(fusb300->ep[i]);
kfree(fusb300);
}
if (reg)
--
2.20.1
[PATCH AUTOSEL 4.9 06/11] ASoC: max98090: remove 24-bit format support if RJ is 0
From: Yu-Hsuan Hsu
[ Upstream commit 5628c8979642a076f91ee86c3bae5ad251639af0 ]
The supported formats are S16_LE and S24_LE now. However, by datasheet
of max98090, S24_LE is only supported when it is in the right justified
mode. We should remove 24-bit format if it is not in that mode to avoid
triggering error.
Signed-off-by: Yu-Hsuan Hsu
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/max98090.c | 16
1 file changed, 16 insertions(+)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index 3e65dc74eb33..e7aef841f87d 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -1924,6 +1924,21 @@ static int max98090_configure_dmic(struct max98090_priv
*max98090,
return 0;
}
+static int max98090_dai_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_component *component = dai->component;
+ struct max98090_priv *max98090 =
snd_soc_component_get_drvdata(component);
+ unsigned int fmt = max98090->dai_fmt;
+
+ /* Remove 24-bit format support if it is not in right justified mode. */
+ if ((fmt & SND_SOC_DAIFMT_FORMAT_MASK) != SND_SOC_DAIFMT_RIGHT_J) {
+ substream->runtime->hw.formats = SNDRV_PCM_FMTBIT_S16_LE;
+ snd_pcm_hw_constraint_msbits(substream->runtime, 0, 16, 16);
+ }
+ return 0;
+}
+
static int max98090_dai_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
@@ -2331,6 +2346,7 @@ EXPORT_SYMBOL_GPL(max98090_mic_detect);
#define MAX98090_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE)
static const struct snd_soc_dai_ops max98090_dai_ops = {
+ .startup = max98090_dai_startup,
.set_sysclk = max98090_dai_set_sysclk,
.set_fmt = max98090_dai_set_fmt,
.set_tdm_slot = max98090_set_tdm_slot,
--
2.20.1
[PATCH AUTOSEL 4.9 02/11] ASoC: soc-pcm: BE dai needs prepare when pause release after resume
From: Libin Yang [ Upstream commit 5087a8f17df868601cd7568299e91c28086d2b45 ] If playback/capture is paused and system enters S3, after system returns from suspend, BE dai needs to call prepare() callback when playback/capture is released from pause if RESUME_INFO flag is not set. Currently, the dpcm_be_dai_prepare() function will block calling prepare() if the pcm is in SND_SOC_DPCM_STATE_PAUSED state. This will cause the following test case fail if the pcm uses BE: playback -> pause -> S3 suspend -> S3 resume -> pause release The playback may exit abnormally when pause is released because the BE dai prepare() is not called. This patch allows dpcm_be_dai_prepare() to call dai prepare() callback in SND_SOC_DPCM_STATE_PAUSED state. Signed-off-by: Libin Yang Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/soc-pcm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 1dbcdc99dbe3..1d00f6e894ef 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -2247,7 +2247,8 @@ int dpcm_be_dai_prepare(struct snd_soc_pcm_runtime *fe, int stream) if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP) && - (be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND)) + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND) && + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED)) continue; dev_dbg(be->dev, "ASoC: prepare BE %s\n", -- 2.20.1
[PATCH AUTOSEL 4.14 10/21] ASoC: sun4i-i2s: Fix sun8i tx channel offset mask
From: Marcus Cooper [ Upstream commit 7e46169a5f35762f335898a75d1b8a242f2ae0f5 ] Although not causing any noticeable issues, the mask for the channel offset is covering too many bits. Signed-off-by: Marcus Cooper Acked-by: Maxime Ripard Acked-by: Chen-Yu Tsai Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/sunxi/sun4i-i2s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c index b4af5ce78ecb..a10913f8293f 100644 --- a/sound/soc/sunxi/sun4i-i2s.c +++ b/sound/soc/sunxi/sun4i-i2s.c @@ -110,7 +110,7 @@ #define SUN8I_I2S_TX_CHAN_MAP_REG 0x44 #define SUN8I_I2S_TX_CHAN_SEL_REG 0x34 -#define SUN8I_I2S_TX_CHAN_OFFSET_MASK GENMASK(13, 11) +#define SUN8I_I2S_TX_CHAN_OFFSET_MASK GENMASK(13, 12) #define SUN8I_I2S_TX_CHAN_OFFSET(offset) (offset << 12) #define SUN8I_I2S_TX_CHAN_EN_MASK GENMASK(11, 4) #define SUN8I_I2S_TX_CHAN_EN(num_chan) (((1 << num_chan) - 1) << 4) -- 2.20.1
[PATCH AUTOSEL 4.14 21/21] ftrace: Fix NULL pointer dereference in free_ftrace_func_mapper()
From: Wei Li
[ Upstream commit 04e03d9a616c19a47178eaca835358610e63a1dd ]
The mapper may be NULL when called from register_ftrace_function_probe()
with probe->data == NULL.
This issue can be reproduced as follow (it may be covered by compiler
optimization sometime):
/ # cat /sys/kernel/debug/tracing/set_ftrace_filter
all functions enabled
/ # echo foo_bar:dump > /sys/kernel/debug/tracing/set_ftrace_filter
[ 206.949100] Unable to handle kernel NULL pointer dereference at virtual
address
[ 206.952402] Mem abort info:
[ 206.952819] ESR = 0x9606
[ 206.955326] Exception class = DABT (current EL), IL = 32 bits
[ 206.955844] SET = 0, FnV = 0
[ 206.956272] EA = 0, S1PTW = 0
[ 206.956652] Data abort info:
[ 206.957320] ISV = 0, ISS = 0x0006
[ 206.959271] CM = 0, WnR = 0
[ 206.959938] user pgtable: 4k pages, 48-bit VAs, pgdp=000419f3a000
[ 206.960483] [] pgd=000411a87003, pud=000411a83003,
pmd=
[ 206.964953] Internal error: Oops: 9606 [#1] SMP
[ 206.971122] Dumping ftrace buffer:
[ 206.973677](ftrace buffer empty)
[ 206.975258] Modules linked in:
[ 206.976631] Process sh (pid: 281, stack limit = 0x(ptrval))
[ 206.978449] CPU: 10 PID: 281 Comm: sh Not tainted 5.2.0-rc1+ #17
[ 206.978955] Hardware name: linux,dummy-virt (DT)
[ 206.979883] pstate: 6005 (nZCv daif -PAN -UAO)
[ 206.980499] pc : free_ftrace_func_mapper+0x2c/0x118
[ 206.980874] lr : ftrace_count_free+0x68/0x80
[ 206.982539] sp : 182f3ab0
[ 206.983102] x29: 182f3ab0 x28: 8003d0ec1700
[ 206.983632] x27: 13054b40 x26: 0001
[ 206.984000] x25: 1385f000 x24:
[ 206.984394] x23: 13453000 x22: 13054000
[ 206.984775] x21: x20: 1385fe28
[ 206.986575] x19: 13872c30 x18:
[ 206.987111] x17: x16:
[ 206.987491] x15: ffb0 x14:
[ 206.987850] x13: 0017430e x12: 0580
[ 206.988251] x11: x10:
[ 206.988740] x9 : x8 : 13917550
[ 206.990198] x7 : 12fac2e8 x6 : 12fac000
[ 206.991008] x5 : 103da588 x4 : 0001
[ 206.991395] x3 : 0001 x2 : 13872a28
[ 206.991771] x1 : x0 :
[ 206.992557] Call trace:
[ 206.993101] free_ftrace_func_mapper+0x2c/0x118
[ 206.994827] ftrace_count_free+0x68/0x80
[ 206.995238] release_probe+0xfc/0x1d0
[ 206.99] register_ftrace_function_probe+0x4a8/0x868
[ 206.995923] ftrace_trace_probe_callback.isra.4+0xb8/0x180
[ 206.996330] ftrace_dump_callback+0x50/0x70
[ 206.996663] ftrace_regex_write.isra.29+0x290/0x3a8
[ 206.997157] ftrace_filter_write+0x44/0x60
[ 206.998971] __vfs_write+0x64/0xf0
[ 206.999285] vfs_write+0x14c/0x2f0
[ 206.999591] ksys_write+0xbc/0x1b0
[ 206.999888] __arm64_sys_write+0x3c/0x58
[ 207.000246] el0_svc_common.constprop.0+0x408/0x5f0
[ 207.000607] el0_svc_handler+0x144/0x1c8
[ 207.000916] el0_svc+0x8/0xc
[ 207.003699] Code: aa0003f8 a9025bf5 aa0103f5 f946ea80 (f9400303)
[ 207.008388] ---[ end trace 7b6d11b5f542bdf1 ]---
[ 207.010126] Kernel panic - not syncing: Fatal exception
[ 207.011322] SMP: stopping secondary CPUs
[ 207.013956] Dumping ftrace buffer:
[ 207.014595](ftrace buffer empty)
[ 207.015632] Kernel Offset: disabled
[ 207.017187] CPU features: 0x002,20006008
[ 207.017985] Memory Limit: none
[ 207.019825] ---[ end Kernel panic - not syncing: Fatal exception ]---
Link: http://lkml.kernel.org/r/20190606031754.10798-1-liwei...@huawei.com
Signed-off-by: Wei Li
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
---
kernel/trace/ftrace.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 4e4b88047fcc..ff3c8ca907c4 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4286,10 +4286,13 @@ void free_ftrace_func_mapper(struct ftrace_func_mapper
*mapper,
struct ftrace_func_entry *entry;
struct ftrace_func_map *map;
struct hlist_head *hhd;
- int size = 1 << mapper->hash.size_bits;
- int i;
+ int size, i;
+
+ if (!mapper)
+ return;
if (free_func && mapper->hash.count) {
+ size = 1 << mapper->hash.size_bits;
for (i = 0; i < size; i++) {
hhd = >hash.buckets[i];
hlist_for_each_entry(entry, hhd, hlist) {
--
2.20.1
[PATCH AUTOSEL 4.14 20/21] module: Fix livepatch/ftrace module text permissions race
From: Josh Poimboeuf
[ Upstream commit 9f255b632bf12c4dd7fc31caee89aa991ef75176 ]
It's possible for livepatch and ftrace to be toggling a module's text
permissions at the same time, resulting in the following panic:
BUG: unable to handle page fault for address: c005b1d9
#PF: supervisor write access in kernel mode
#PF: error_code(0x0003) - permissions violation
PGD 3ea0c067 P4D 3ea0c067 PUD 3ea0e067 PMD 3cc13067 PTE 3b8a1061
Oops: 0003 [#1] PREEMPT SMP PTI
CPU: 1 PID: 453 Comm: insmod Tainted: G O K 5.2.0-rc1-a188339ca5
#1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-20181126_142135-anatol 04/01/2014
RIP: 0010:apply_relocate_add+0xbe/0x14c
Code: fa 0b 74 21 48 83 fa 18 74 38 48 83 fa 0a 75 40 eb 08 48 83 38 00 74 33
eb 53 83 38 00 75 4e 89 08 89 c8 eb 0a 83 38 00 75 43 <89> 08 48 63 c1 48 39 c8
74 2e eb 48 83 38 00 75 32 48 29 c1 89 08
RSP: 0018:b223c00dbb10 EFLAGS: 00010246
RAX: c005b1d9 RBX: RCX: 8b200060
RDX: 000b RSI: 004b000b RDI: 96bdfcd33000
RBP: b223c00dbb38 R08: c005d040 R09: c005c1f0
R10: 96bdfcd33c40 R11: 96bdfcd33b80 R12: 0018
R13: c005c1f0 R14: c005e708 R15: 8b2fbc74
FS: 7f5f447beba8() GS:96bdff90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: c005b1d9 CR3: 3cedc002 CR4: 00360ea0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
klp_init_object_loaded+0x10f/0x219
? preempt_latency_start+0x21/0x57
klp_enable_patch+0x662/0x809
? virt_to_head_page+0x3a/0x3c
? kfree+0x8c/0x126
patch_init+0x2ed/0x1000 [livepatch_test02]
? 0xc006
do_one_initcall+0x9f/0x1c5
? kmem_cache_alloc_trace+0xc4/0xd4
? do_init_module+0x27/0x210
do_init_module+0x5f/0x210
load_module+0x1c41/0x2290
? fsnotify_path+0x3b/0x42
? strstarts+0x2b/0x2b
? kernel_read+0x58/0x65
__do_sys_finit_module+0x9f/0xc3
? __do_sys_finit_module+0x9f/0xc3
__x64_sys_finit_module+0x1a/0x1c
do_syscall_64+0x52/0x61
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The above panic occurs when loading two modules at the same time with
ftrace enabled, where at least one of the modules is a livepatch module:
CPU0CPU1
klp_enable_patch()
klp_init_object_loaded()
module_disable_ro()
ftrace_module_enable()
ftrace_arch_code_modify_post_process()
set_all_modules_text_ro()
klp_write_object_relocations()
apply_relocate_add()
*patches read-only code* - BOOM
A similar race exists when toggling ftrace while loading a livepatch
module.
Fix it by ensuring that the livepatch and ftrace code patching
operations -- and their respective permissions changes -- are protected
by the text_mutex.
Link:
http://lkml.kernel.org/r/ab43d56ab909469ac5d2520c5d944ad6d4abd476.1560474114.git.jpoim...@redhat.com
Reported-by: Johannes Erdfelt
Fixes: 444d13ff10fb ("modules: add ro_after_init support")
Acked-by: Jessica Yu
Reviewed-by: Petr Mladek
Reviewed-by: Miroslav Benes
Signed-off-by: Josh Poimboeuf
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
---
kernel/livepatch/core.c | 6 ++
kernel/trace/ftrace.c | 10 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 7c51f065b212..88754e9790f9 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include "core.h"
#include "patch.h"
@@ -635,16 +636,21 @@ static int klp_init_object_loaded(struct klp_patch *patch,
struct klp_func *func;
int ret;
+ mutex_lock(_mutex);
+
module_disable_ro(patch->mod);
ret = klp_write_object_relocations(patch->mod, obj);
if (ret) {
module_enable_ro(patch->mod, true);
+ mutex_unlock(_mutex);
return ret;
}
arch_klp_init_object_loaded(patch, obj);
module_enable_ro(patch->mod, true);
+ mutex_unlock(_mutex);
+
klp_for_each_func(obj, func) {
ret = klp_find_object_symbol(obj->name, func->old_name,
func->old_sympos,
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 3e92852c8b23..4e4b88047fcc 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -2692,10 +2693,12 @@ static void ftrace_run_update_code(int command)
{
int ret;
+ mutex_lock(_mutex);
+
ret =
[PATCH AUTOSEL 4.9 03/11] spi: bitbang: Fix NULL pointer dereference in spi_unregister_master
From: YueHaibing
[ Upstream commit 5caaf29af5ca82d5da8bc1d0ad07d9e664ccf1d8 ]
If spi_register_master fails in spi_bitbang_start
because device_add failure, We should return the
error code other than 0, otherwise calling
spi_bitbang_stop may trigger NULL pointer dereference
like this:
BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0
Read of size 8 at addr by task syz-executor.0/3661
CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
04/01/2014
Call Trace:
dump_stack+0xa9/0x10e
? __list_del_entry_valid+0x45/0xd0
? __list_del_entry_valid+0x45/0xd0
__kasan_report+0x171/0x18d
? __list_del_entry_valid+0x45/0xd0
kasan_report+0xe/0x20
__list_del_entry_valid+0x45/0xd0
spi_unregister_controller+0x99/0x1b0
spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp]
? 0xc1128000
? klist_next+0x131/0x1e0
? driver_detach+0x40/0x40 [parport]
port_check+0x3b/0x50 [parport]
bus_for_each_dev+0x115/0x180
? subsys_dev_iter_exit+0x20/0x20
__parport_register_driver+0x1f0/0x210 [parport]
? 0xc115
do_one_initcall+0xb9/0x3b5
? perf_trace_initcall_level+0x270/0x270
? kasan_unpoison_shadow+0x30/0x40
? kasan_unpoison_shadow+0x30/0x40
do_init_module+0xe0/0x330
load_module+0x38eb/0x4270
? module_frob_arch_sections+0x20/0x20
? kernel_read_file+0x188/0x3f0
? find_held_lock+0x6d/0xd0
? fput_many+0x1a/0xe0
? __do_sys_finit_module+0x162/0x190
__do_sys_finit_module+0x162/0x190
? __ia32_sys_init_module+0x40/0x40
? __mutex_unlock_slowpath+0xb4/0x3f0
? wait_for_completion+0x240/0x240
? vfs_write+0x160/0x2a0
? lockdep_hardirqs_off+0xb5/0x100
? mark_held_locks+0x1a/0x90
? do_syscall_64+0x14/0x2a0
do_syscall_64+0x72/0x2a0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Reported-by: Hulk Robot
Fixes: 702a4879ec33 ("spi: bitbang: Let spi_bitbang_start() take a reference to
master")
Signed-off-by: YueHaibing
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Axel Lin
Reviewed-by: Mukesh Ojha
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi-bitbang.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-bitbang.c b/drivers/spi/spi-bitbang.c
index 3aa9e6e3dac8..4ef54436b9d4 100644
--- a/drivers/spi/spi-bitbang.c
+++ b/drivers/spi/spi-bitbang.c
@@ -392,7 +392,7 @@ int spi_bitbang_start(struct spi_bitbang *bitbang)
if (ret)
spi_master_put(master);
- return 0;
+ return ret;
}
EXPORT_SYMBOL_GPL(spi_bitbang_start);
--
2.20.1
[PATCH AUTOSEL 4.14 12/21] usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i]
From: Young Xiao <92siuy...@gmail.com>
[ Upstream commit 62fd0e0a24abeebe2c19fce49dd5716d9b62042d ]
There is no deallocation of fusb300->ep[i] elements, allocated at
fusb300_probe.
The patch adds deallocation of fusb300->ep array elements.
Signed-off-by: Young Xiao <92siuy...@gmail.com>
Signed-off-by: Felipe Balbi
Signed-off-by: Sasha Levin
---
drivers/usb/gadget/udc/fusb300_udc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/gadget/udc/fusb300_udc.c
b/drivers/usb/gadget/udc/fusb300_udc.c
index e0c1b0099265..089f39de6897 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -1345,12 +1345,15 @@ static const struct usb_gadget_ops fusb300_gadget_ops =
{
static int fusb300_remove(struct platform_device *pdev)
{
struct fusb300 *fusb300 = platform_get_drvdata(pdev);
+ int i;
usb_del_gadget_udc(>gadget);
iounmap(fusb300->reg);
free_irq(platform_get_irq(pdev, 0), fusb300);
fusb300_free_request(>ep[0]->ep, fusb300->ep0_req);
+ for (i = 0; i < FUSB300_MAX_NUM_EP; i++)
+ kfree(fusb300->ep[i]);
kfree(fusb300);
return 0;
@@ -1494,6 +1497,8 @@ static int fusb300_probe(struct platform_device *pdev)
if (fusb300->ep0_req)
fusb300_free_request(>ep[0]->ep,
fusb300->ep0_req);
+ for (i = 0; i < FUSB300_MAX_NUM_EP; i++)
+ kfree(fusb300->ep[i]);
kfree(fusb300);
}
if (reg)
--
2.20.1
[PATCH AUTOSEL 4.14 11/21] ASoC: sun4i-i2s: Add offset to RX channel select
From: Marcus Cooper [ Upstream commit f9927000cb35f250051f0f1878db12ee2626eea1 ] Whilst testing the capture functionality of the i2s on the newer SoCs it was noticed that the recording was somewhat distorted. This was due to the offset not being set correctly on the receiver side. Signed-off-by: Marcus Cooper Acked-by: Maxime Ripard Acked-by: Chen-Yu Tsai Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/sunxi/sun4i-i2s.c | 4 1 file changed, 4 insertions(+) diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c index a10913f8293f..da0a2083e12a 100644 --- a/sound/soc/sunxi/sun4i-i2s.c +++ b/sound/soc/sunxi/sun4i-i2s.c @@ -442,6 +442,10 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG, SUN8I_I2S_TX_CHAN_OFFSET_MASK, SUN8I_I2S_TX_CHAN_OFFSET(offset)); + + regmap_update_bits(i2s->regmap, SUN8I_I2S_RX_CHAN_SEL_REG, + SUN8I_I2S_TX_CHAN_OFFSET_MASK, + SUN8I_I2S_TX_CHAN_OFFSET(offset)); } regmap_field_write(i2s->field_fmt_mode, val); -- 2.20.1
[PATCH AUTOSEL 4.14 17/21] cpuset: restore sanity to cpuset_cpus_allowed_fallback()
From: Joel Savitz [ Upstream commit d477f8c202d1f0d4791ab1263ca7657bbe5cf79e ] In the case that a process is constrained by taskset(1) (i.e. sched_setaffinity(2)) to a subset of available cpus, and all of those are subsequently offlined, the scheduler will set tsk->cpus_allowed to the current value of task_cs(tsk)->effective_cpus. This is done via a call to do_set_cpus_allowed() in the context of cpuset_cpus_allowed_fallback() made by the scheduler when this case is detected. This is the only call made to cpuset_cpus_allowed_fallback() in the latest mainline kernel. However, this is not sane behavior. I will demonstrate this on a system running the latest upstream kernel with the following initial configuration: # grep -i cpu /proc/$$/status Cpus_allowed: ,fff Cpus_allowed_list: 0-63 (Where cpus 32-63 are provided via smt.) If we limit our current shell process to cpu2 only and then offline it and reonline it: # taskset -p 4 $$ pid 2272's current affinity mask: pid 2272's new affinity mask: 4 # echo off > /sys/devices/system/cpu/cpu2/online # dmesg | tail -3 [ 2195.866089] process 2272 (bash) no longer affine to cpu2 [ 2195.872700] IRQ 114: no longer affine to CPU2 [ 2195.879128] smpboot: CPU 2 is now offline # echo on > /sys/devices/system/cpu/cpu2/online # dmesg | tail -1 [ 2617.043572] smpboot: Booting Node 0 Processor 2 APIC 0x4 We see that our current process now has an affinity mask containing every cpu available on the system _except_ the one we originally constrained it to: # grep -i cpu /proc/$$/status Cpus_allowed: ,fffb Cpus_allowed_list: 0-1,3-63 This is not sane behavior, as the scheduler can now not only place the process on previously forbidden cpus, it can't even schedule it on the cpu it was originally constrained to! Other cases result in even more exotic affinity masks. Take for instance a process with an affinity mask containing only cpus provided by smt at the moment that smt is toggled, in a configuration such as the following: # taskset -p f0 $$ # grep -i cpu /proc/$$/status Cpus_allowed: 00f0, Cpus_allowed_list: 36-39 A double toggle of smt results in the following behavior: # echo off > /sys/devices/system/cpu/smt/control # echo on > /sys/devices/system/cpu/smt/control # grep -i cpus /proc/$$/status Cpus_allowed: ff00, Cpus_allowed_list: 0-31,40-63 This is even less sane than the previous case, as the new affinity mask excludes all smt-provided cpus with ids less than those that were previously in the affinity mask, as well as those that were actually in the mask. With this patch applied, both of these cases end in the following state: # grep -i cpu /proc/$$/status Cpus_allowed: , Cpus_allowed_list: 0-63 The original policy is discarded. Though not ideal, it is the simplest way to restore sanity to this fallback case without reinventing the cpuset wheel that rolls down the kernel just fine in cgroup v2. A user who wishes for the previous affinity mask to be restored in this fallback case can use that mechanism instead. This patch modifies scheduler behavior by instead resetting the mask to task_cs(tsk)->cpus_allowed by default, and cpu_possible mask in legacy mode. I tested the cases above on both modes. Note that the scheduler uses this fallback mechanism if and only if _every_ other valid avenue has been traveled, and it is the last resort before calling BUG(). Suggested-by: Waiman Long Suggested-by: Phil Auld Signed-off-by: Joel Savitz Acked-by: Phil Auld Acked-by: Waiman Long Acked-by: Peter Zijlstra (Intel) Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin --- kernel/cgroup/cpuset.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 4657e2924ecb..0a0e1aa11f5e 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -2436,10 +2436,23 @@ void cpuset_cpus_allowed(struct task_struct *tsk, struct cpumask *pmask) spin_unlock_irqrestore(_lock, flags); } +/** + * cpuset_cpus_allowed_fallback - final fallback before complete catastrophe. + * @tsk: pointer to task_struct with which the scheduler is struggling + * + * Description: In the case that the scheduler cannot find an allowed cpu in + * tsk->cpus_allowed, we fall back to task_cs(tsk)->cpus_allowed. In legacy + * mode however, this value is the same as task_cs(tsk)->effective_cpus, + * which will not contain a sane cpumask during cases such as cpu hotplugging. + * This is the absolute last resort for the scheduler and it is only used if + * _every_ other avenue has been traveled. + **/ + void cpuset_cpus_allowed_fallback(struct
[PATCH AUTOSEL 4.19 27/34] platform/mellanox: mlxreg-hotplug: Add devm_free_irq call to remove flow
From: Vadim Pasternak
[ Upstream commit 8c2eb7b6468ad4aa5600aed01aa0715f921a3f8b ]
Add devm_free_irq() call to mlxreg-hotplug remove() for clean release
of devices irq resource. Fix debugobjects warning triggered by rmmod
It prevents of use-after-free memory, related to
mlxreg_hotplug_work_handler.
Issue has been reported as debugobjects warning triggered by
'rmmod mlxtreg-hotplug' flow, while running kernel with
CONFIG_DEBUG_OBJECTS* options.
[ 2489.623551] ODEBUG: free active (active state 0) object type: work_struct
hint: mlxreg_hotplug_work_handler+0x0/0x7f0 [mlxreg_hotplug]
[ 2489.637097] WARNING: CPU: 5 PID: 3924 at lib/debugobjects.c:328
debug_print_object+0xfe/0x180
[ 2489.637165] RIP: 0010:debug_print_object+0xfe/0x180
?
[ 2489.637214] Call Trace:
[ 2489.637225] __debug_check_no_obj_freed+0x25e/0x320
[ 2489.637231] kfree+0x82/0x110
[ 2489.637238] release_nodes+0x33c/0x4e0
[ 2489.637242] ? devres_remove_group+0x1b0/0x1b0
[ 2489.637247] device_release_driver_internal+0x146/0x270
[ 2489.637251] driver_detach+0x73/0xe0
[ 2489.637254] bus_remove_driver+0xa1/0x170
[ 2489.637261] __x64_sys_delete_module+0x29e/0x320
[ 2489.637265] ? __ia32_sys_delete_module+0x320/0x320
[ 2489.637268] ? blkcg_exit_queue+0x20/0x20
[ 2489.637273] ? task_work_run+0x7d/0x100
[ 2489.637278] ? exit_to_usermode_loop+0x5b/0xf0
[ 2489.637281] do_syscall_64+0x73/0x160
[ 2489.637287] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 2489.637290] RIP: 0033:0x7f95c3596fd7
The difference in release flow with and with no devm_free_irq is listed
below:
bus: 'platform': remove driver mlxreg-hotplug
mlxreg_hotplug_remove(start)
-> devm_free_irq (with new code)
mlxreg_hotplug_remove (end)
release_nodes (start)
mlxreg-hotplug: DEVRES REL devm_hwmon_release (8 bytes)
device: 'hwmon3': device_unregister
PM: Removing info for No Bus:hwmon3
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (88 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (6 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
mlxreg-hotplug: DEVRES REL devm_irq_release (16 bytes) (no new code)
mlxreg-hotplug: DEVRES REL devm_kzalloc_release (1376 bytes)
[ cut here ] (no new code):
ODEBUG: free active (active state 0) object type: work_struct hint:
mlxreg_hotplug_work_handler
release_nodes(end)
driver: 'mlxreg-hotplug': driver_release
Fixes: 1f976f6978bf ("platform/x86: Move Mellanox platform hotplug driver to
platform/mellanox")
Signed-off-by: Vadim Pasternak
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
---
drivers/platform/mellanox/mlxreg-hotplug.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c
b/drivers/platform/mellanox/mlxreg-hotplug.c
index eca16d00e310..d52c821b8584 100644
--- a/drivers/platform/mellanox/mlxreg-hotplug.c
+++ b/drivers/platform/mellanox/mlxreg-hotplug.c
@@ -673,6 +673,7 @@ static int mlxreg_hotplug_remove(struct platform_device
*pdev)
/* Clean interrupts setup. */
mlxreg_hotplug_unset_irq(priv);
+ devm_free_irq(>dev, priv->irq, priv);
return 0;
}
--
2.20.1
[PATCH AUTOSEL 4.14 13/21] usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC
From: Alexandre Belloni [ Upstream commit fbc318afadd6e7ae2252d6158cf7d0c5a2132f7d ] Gadget drivers may queue request in interrupt context. This would lead to a descriptor allocation in that context. In that case we would hit BUG_ON(in_interrupt()) in __get_vm_area_node. Also remove the unnecessary cast. Acked-by: Sylvain Lemieux Tested-by: James Grant Signed-off-by: Alexandre Belloni Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin --- drivers/usb/gadget/udc/lpc32xx_udc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c b/drivers/usb/gadget/udc/lpc32xx_udc.c index 8f32b5ee7734..6df1aded4503 100644 --- a/drivers/usb/gadget/udc/lpc32xx_udc.c +++ b/drivers/usb/gadget/udc/lpc32xx_udc.c @@ -935,8 +935,7 @@ static struct lpc32xx_usbd_dd_gad *udc_dd_alloc(struct lpc32xx_udc *udc) dma_addr_t dma; struct lpc32xx_usbd_dd_gad *dd; - dd = (struct lpc32xx_usbd_dd_gad *) dma_pool_alloc( - udc->dd_cache, (GFP_KERNEL | GFP_DMA), ); + dd = dma_pool_alloc(udc->dd_cache, GFP_ATOMIC | GFP_DMA, ); if (dd) dd->this_dma = dma; -- 2.20.1
