From: Amol Grover frextrite@gmail.com
[ Upstream commit bc62d68e2a0a69fcdcf28aca8edb01abf306b698 ]
exceptions may be traversed using list_for_each_entry_rcu() outside of an RCU read side critical section BUT under the protection of decgroup_mutex. Hence add the corresponding lockdep expression to fix the following false-positive warning:
[ 2.304417] ============================= [ 2.304418] WARNING: suspicious RCU usage [ 2.304420] 5.5.4-stable #17 Tainted: G E [ 2.304422] ----------------------------- [ 2.304424] security/device_cgroup.c:355 RCU-list traversed in non-reader section!!
Signed-off-by: Amol Grover frextrite@gmail.com Signed-off-by: James Morris jmorris@namei.org Signed-off-by: Sasha Levin sashal@kernel.org --- security/device_cgroup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/device_cgroup.c b/security/device_cgroup.c index 43ab0ad45c1b6..04375df52fc9a 100644 --- a/security/device_cgroup.c +++ b/security/device_cgroup.c @@ -354,7 +354,8 @@ static bool match_exception_partial(struct list_head *exceptions, short type, { struct dev_exception_item *ex;
- list_for_each_entry_rcu(ex, exceptions, list) { + list_for_each_entry_rcu(ex, exceptions, list, + lockdep_is_held(&devcgroup_mutex)) { if ((type & DEVCG_DEV_BLOCK) && !(ex->type & DEVCG_DEV_BLOCK)) continue; if ((type & DEVCG_DEV_CHAR) && !(ex->type & DEVCG_DEV_CHAR))
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
[ Upstream commit 7ad26d6671db758c959d7e1d100b138a38483612 ]
Some sound card try to set 0 Hz as reset, but it is impossible. This patch ignores it to avoid error return.
Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87a6yjy5sy.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/codecs/pcm3168a.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/sound/soc/codecs/pcm3168a.c b/sound/soc/codecs/pcm3168a.c index 9711fab296ebc..045c6f8b26bef 100644 --- a/sound/soc/codecs/pcm3168a.c +++ b/sound/soc/codecs/pcm3168a.c @@ -306,6 +306,13 @@ static int pcm3168a_set_dai_sysclk(struct snd_soc_dai *dai, struct pcm3168a_priv *pcm3168a = snd_soc_component_get_drvdata(dai->component); int ret;
+ /* + * Some sound card sets 0 Hz as reset, + * but it is impossible to set. Ignore it here + */ + if (freq == 0) + return 0; + if (freq > PCM3168A_MAX_SYSCLK) return -EINVAL;
From: Sylwester Nawrocki s.nawrocki@samsung.com
[ Upstream commit 811c5494436789e7149487c06e0602b507ce274b ]
The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip initialization of that register for that device. This suppresses an error during boot: "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
Signed-off-by: Sylwester Nawrocki s.nawrocki@samsung.com Acked-by: Krzysztof Kozlowski krzk@kernel.org Acked-by: Charles Keepax ckeepax@opensource.cirrus.com Link: https://lore.kernel.org/r/20200827173357.31891-1-s.nawrocki@samsung.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/codecs/wm8994.c | 2 ++ sound/soc/codecs/wm_hubs.c | 3 +++ sound/soc/codecs/wm_hubs.h | 1 + 3 files changed, 6 insertions(+)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 55d0b9be6ff00..c2116836a7203 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -4166,11 +4166,13 @@ static int wm8994_component_probe(struct snd_soc_component *component) wm8994->hubs.dcs_readback_mode = 2; break; } + wm8994->hubs.micd_scthr = true; break;
case WM8958: wm8994->hubs.dcs_readback_mode = 1; wm8994->hubs.hp_startup_mode = 1; + wm8994->hubs.micd_scthr = true;
switch (control->revision) { case 0: diff --git a/sound/soc/codecs/wm_hubs.c b/sound/soc/codecs/wm_hubs.c index e93af7edd8f75..dd421e2fe7b21 100644 --- a/sound/soc/codecs/wm_hubs.c +++ b/sound/soc/codecs/wm_hubs.c @@ -1223,6 +1223,9 @@ int wm_hubs_handle_analogue_pdata(struct snd_soc_component *component, snd_soc_component_update_bits(component, WM8993_ADDITIONAL_CONTROL, WM8993_LINEOUT2_FB, WM8993_LINEOUT2_FB);
+ if (!hubs->micd_scthr) + return 0; + snd_soc_component_update_bits(component, WM8993_MICBIAS, WM8993_JD_SCTHR_MASK | WM8993_JD_THR_MASK | WM8993_MICB1_LVL | WM8993_MICB2_LVL, diff --git a/sound/soc/codecs/wm_hubs.h b/sound/soc/codecs/wm_hubs.h index 4b8e5f0d6e32d..988b29e630607 100644 --- a/sound/soc/codecs/wm_hubs.h +++ b/sound/soc/codecs/wm_hubs.h @@ -27,6 +27,7 @@ struct wm_hubs_data { int hp_startup_mode; int series_startup; int no_series_update; + bool micd_scthr;
bool no_cache_dac_hp_direct; struct list_head dcs_cache;
On Mon, Sep 21, 2020 at 10:40:10AM -0400, Sasha Levin wrote:
The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip initialization of that register for that device. This suppresses an error during boot: "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
This is pretty much a cosmetic change - previously we were silently not reading the register, this just removes the attempt to read it since we added an error message in the core.
On Mon, Sep 21, 2020 at 04:07:01PM +0100, Mark Brown wrote:
On Mon, Sep 21, 2020 at 10:40:10AM -0400, Sasha Levin wrote:
The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip initialization of that register for that device. This suppresses an error during boot: "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
This is pretty much a cosmetic change - previously we were silently not reading the register, this just removes the attempt to read it since we added an error message in the core.
Right, the only reason I took it is that error message - I find that bogus error messages have almost the same (bad) impact as real kernel bugs.
I can drop it if you'd prefer.
On Tue, Sep 22, 2020 at 10:25:15AM -0400, Sasha Levin wrote:
On Mon, Sep 21, 2020 at 04:07:01PM +0100, Mark Brown wrote:
This is pretty much a cosmetic change - previously we were silently not reading the register, this just removes the attempt to read it since we added an error message in the core.
Right, the only reason I took it is that error message - I find that bogus error messages have almost the same (bad) impact as real kernel bugs.
The point is that the error message isn't present in stable kernels so there is no impact on any user visible behaviour.
On Tue, Sep 22, 2020 at 03:42:21PM +0100, Mark Brown wrote:
On Tue, Sep 22, 2020 at 10:25:15AM -0400, Sasha Levin wrote:
On Mon, Sep 21, 2020 at 04:07:01PM +0100, Mark Brown wrote:
This is pretty much a cosmetic change - previously we were silently not reading the register, this just removes the attempt to read it since we added an error message in the core.
Right, the only reason I took it is that error message - I find that bogus error messages have almost the same (bad) impact as real kernel bugs.
The point is that the error message isn't present in stable kernels so there is no impact on any user visible behaviour.
Ah, I see. I'll drop it. Thanks!
From: Sylwester Nawrocki s.nawrocki@samsung.com
[ Upstream commit f5a2cda4f1db89776b64c4f0f2c2ac609527ac70 ]
When the wm8958_mic_detect, wm8994_mic_detect functions get called from the machine driver, e.g. from the card's late_probe() callback, the CODEC device may be PM runtime suspended and any regmap writes have no effect. Add PM runtime calls to these functions to ensure the device registers are updated as expected. This suppresses an error during boot "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec" caused by the regmap access error due to the cache_only flag being set.
Signed-off-by: Sylwester Nawrocki s.nawrocki@samsung.com Acked-by: Krzysztof Kozlowski krzk@kernel.org Acked-by: Charles Keepax ckeepax@opensource.cirrus.com Link: https://lore.kernel.org/r/20200827173357.31891-2-s.nawrocki@samsung.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/codecs/wm8994.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index c2116836a7203..58f21329d0e99 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -3491,6 +3491,8 @@ int wm8994_mic_detect(struct snd_soc_component *component, struct snd_soc_jack * return -EINVAL; }
+ pm_runtime_get_sync(component->dev); + switch (micbias) { case 1: micdet = &wm8994->micdet[0]; @@ -3538,6 +3540,8 @@ int wm8994_mic_detect(struct snd_soc_component *component, struct snd_soc_jack *
snd_soc_dapm_sync(dapm);
+ pm_runtime_put(component->dev); + return 0; } EXPORT_SYMBOL_GPL(wm8994_mic_detect); @@ -3905,6 +3909,8 @@ int wm8958_mic_detect(struct snd_soc_component *component, struct snd_soc_jack * return -EINVAL; }
+ pm_runtime_get_sync(component->dev); + if (jack) { snd_soc_dapm_force_enable_pin(dapm, "CLK_SYS"); snd_soc_dapm_sync(dapm); @@ -3973,6 +3979,8 @@ int wm8958_mic_detect(struct snd_soc_component *component, struct snd_soc_jack * snd_soc_dapm_sync(dapm); }
+ pm_runtime_put(component->dev); + return 0; } EXPORT_SYMBOL_GPL(wm8958_mic_detect);
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit 6a0137101f47301fff2da6ba4b9048383d569909 ]
The MPMAN Converter9 2-in-1 almost fully works with out default settings. The only problem is that it has only 1 speaker so any sounds only playing on the right channel get lost.
Add a quirk for this model using the default settings + MONO_SPEAKER.
Signed-off-by: Hans de Goede hdegoede@redhat.com Acked-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Link: https://lore.kernel.org/r/20200901080623.4987-1-hdegoede@redhat.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/intel/boards/bytcr_rt5640.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 1fdb70b9e4788..5f885062145fe 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -591,6 +591,16 @@ static const struct dmi_system_id byt_rt5640_quirk_table[] = { BYT_RT5640_SSP0_AIF1 | BYT_RT5640_MCLK_EN), }, + { /* MPMAN Converter 9, similar hw as the I.T.Works TW891 2-in-1 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "MPMAN"), + DMI_MATCH(DMI_PRODUCT_NAME, "Converter9"), + }, + .driver_data = (void *)(BYTCR_INPUT_DEFAULTS | + BYT_RT5640_MONO_SPEAKER | + BYT_RT5640_SSP0_AIF1 | + BYT_RT5640_MCLK_EN), + }, { /* MPMAN MPWIN895CL */ .matches = {
From: Sumera Priyadarsini sylphrenadin@gmail.com
[ Upstream commit da9c43dc0e2ec5c42a3d414e389feb30467000e2 ]
Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node, however when control is transferred from the middle of the loop, as in the case of a return or break or goto, there is no decrement thus ultimately resulting in a memory leak.
Fix a potential memory leak in clk-impd1.c by inserting of_node_put() before a return statement.
Issue found with Coccinelle.
Signed-off-by: Sumera Priyadarsini sylphrenadin@gmail.com Link: https://lore.kernel.org/r/20200829175704.GA10998@Kaladin Reviewed-by: Linus Walleij linus.walleij@linaro.org Signed-off-by: Stephen Boyd sboyd@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/clk/versatile/clk-impd1.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/versatile/clk-impd1.c b/drivers/clk/versatile/clk-impd1.c index ca798249544d0..85c395df9c008 100644 --- a/drivers/clk/versatile/clk-impd1.c +++ b/drivers/clk/versatile/clk-impd1.c @@ -109,8 +109,10 @@ static int integrator_impd1_clk_probe(struct platform_device *pdev)
for_each_available_child_of_node(np, child) { ret = integrator_impd1_clk_spawn(dev, np, child); - if (ret) + if (ret) { + of_node_put(child); break; + } }
return ret;
From: Palmer Dabbelt palmerdabbelt@google.com
[ Upstream commit 66d18dbda8469a944dfec6c49d26d5946efba218 ]
Without this we get lockdep failures. They're spurious failures as SMP isn't up when ftrace_init_nop() is called. As far as I can tell the easiest fix is to just take the lock, which also seems like the safest fix.
Signed-off-by: Palmer Dabbelt palmerdabbelt@google.com Acked-by: Guo Ren guoren@kernel.org Signed-off-by: Palmer Dabbelt palmerdabbelt@google.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/riscv/include/asm/ftrace.h | 7 +++++++ arch/riscv/kernel/ftrace.c | 19 +++++++++++++++++++ 2 files changed, 26 insertions(+)
diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h index ace8a6e2d11d3..845002cc2e571 100644 --- a/arch/riscv/include/asm/ftrace.h +++ b/arch/riscv/include/asm/ftrace.h @@ -66,6 +66,13 @@ do { \ * Let auipc+jalr be the basic *mcount unit*, so we make it 8 bytes here. */ #define MCOUNT_INSN_SIZE 8 + +#ifndef __ASSEMBLY__ +struct dyn_ftrace; +int ftrace_init_nop(struct module *mod, struct dyn_ftrace *rec); +#define ftrace_init_nop ftrace_init_nop +#endif + #endif
#endif /* _ASM_RISCV_FTRACE_H */ diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c index 2ff63d0cbb500..99e12faa54986 100644 --- a/arch/riscv/kernel/ftrace.c +++ b/arch/riscv/kernel/ftrace.c @@ -97,6 +97,25 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec, return __ftrace_modify_call(rec->ip, addr, false); }
+ +/* + * This is called early on, and isn't wrapped by + * ftrace_arch_code_modify_{prepare,post_process}() and therefor doesn't hold + * text_mutex, which triggers a lockdep failure. SMP isn't running so we could + * just directly poke the text, but it's simpler to just take the lock + * ourselves. + */ +int ftrace_init_nop(struct module *mod, struct dyn_ftrace *rec) +{ + int out; + + ftrace_arch_code_modify_prepare(); + out = ftrace_make_nop(mod, rec, MCOUNT_ADDR); + ftrace_arch_code_modify_post_process(); + + return out; +} + int ftrace_update_ftrace_func(ftrace_func_t func) { int ret = __ftrace_modify_call((unsigned long)&ftrace_call,
From: Eddie James eajames@linux.ibm.com
[ Upstream commit 1a1d6db23ddacde0b15ea589e9103373e05af8de ]
Mask the IRQ status to only the bits that the driver checks. This prevents excessive driver warnings when operating in slave mode when additional bits are set that the driver doesn't handle.
Signed-off-by: Eddie James eajames@linux.ibm.com Reviewed-by: Tao Ren rentao.bupt@gmail.com Signed-off-by: Wolfram Sang wsa@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/i2c/busses/i2c-aspeed.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c index f51702d86a90e..1ad74efcab372 100644 --- a/drivers/i2c/busses/i2c-aspeed.c +++ b/drivers/i2c/busses/i2c-aspeed.c @@ -69,6 +69,7 @@ * These share bit definitions, so use the same values for the enable & * status bits. */ +#define ASPEED_I2CD_INTR_RECV_MASK 0xf000ffff #define ASPEED_I2CD_INTR_SDA_DL_TIMEOUT BIT(14) #define ASPEED_I2CD_INTR_BUS_RECOVER_DONE BIT(13) #define ASPEED_I2CD_INTR_SLAVE_MATCH BIT(7) @@ -604,6 +605,7 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id) writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE, bus->base + ASPEED_I2C_INTR_STS_REG); readl(bus->base + ASPEED_I2C_INTR_STS_REG); + irq_received &= ASPEED_I2CD_INTR_RECV_MASK; irq_remaining = irq_received;
#if IS_ENABLED(CONFIG_I2C_SLAVE)
From: Ilya Leoshkevich iii@linux.ibm.com
[ Upstream commit fcb2b70cdb194157678fb1a75f9ff499aeba3d2a ]
Add __init to reserve_memory_end, reserve_oldmem and remove_oldmem. Sometimes these functions are not inlined, and then the build complains about section mismatch.
Signed-off-by: Ilya Leoshkevich iii@linux.ibm.com Signed-off-by: Heiko Carstens hca@linux.ibm.com Signed-off-by: Vasily Gorbik gor@linux.ibm.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/s390/kernel/setup.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c index 07aa15ba43b3e..faf30f37c6361 100644 --- a/arch/s390/kernel/setup.c +++ b/arch/s390/kernel/setup.c @@ -619,7 +619,7 @@ static struct notifier_block kdump_mem_nb = { /* * Make sure that the area behind memory_end is protected */ -static void reserve_memory_end(void) +static void __init reserve_memory_end(void) { if (memory_end_set) memblock_reserve(memory_end, ULONG_MAX); @@ -628,7 +628,7 @@ static void reserve_memory_end(void) /* * Make sure that oldmem, where the dump is stored, is protected */ -static void reserve_oldmem(void) +static void __init reserve_oldmem(void) { #ifdef CONFIG_CRASH_DUMP if (OLDMEM_BASE) @@ -640,7 +640,7 @@ static void reserve_oldmem(void) /* * Make sure that oldmem, where the dump is stored, is protected */ -static void remove_oldmem(void) +static void __init remove_oldmem(void) { #ifdef CONFIG_CRASH_DUMP if (OLDMEM_BASE)
From: Sven Schnelle svens@linux.ibm.com
[ Upstream commit 73ac74c7d489756d2313219a108809921dbfaea1 ]
Switch order so that locking state is consistent even if the IRQ tracer calls into lockdep again.
Acked-by: Peter Zijlstra peterz@infradead.org Signed-off-by: Sven Schnelle svens@linux.ibm.com Signed-off-by: Vasily Gorbik gor@linux.ibm.com Signed-off-by: Sasha Levin sashal@kernel.org --- kernel/trace/trace_preemptirq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c index f10073e626030..f4938040c2286 100644 --- a/kernel/trace/trace_preemptirq.c +++ b/kernel/trace/trace_preemptirq.c @@ -102,14 +102,14 @@ NOKPROBE_SYMBOL(trace_hardirqs_on_caller);
__visible void trace_hardirqs_off_caller(unsigned long caller_addr) { + lockdep_hardirqs_off(CALLER_ADDR0); + if (!this_cpu_read(tracing_irq_cpu)) { this_cpu_write(tracing_irq_cpu, 1); tracer_hardirqs_off(CALLER_ADDR0, caller_addr); if (!in_nmi()) trace_irq_disable_rcuidle(CALLER_ADDR0, caller_addr); } - - lockdep_hardirqs_off(CALLER_ADDR0); } EXPORT_SYMBOL(trace_hardirqs_off_caller); NOKPROBE_SYMBOL(trace_hardirqs_off_caller);
From: Borislav Petkov bp@suse.de
[ Upstream commit 251c54ea26fa6029b01a76161a37a12fde5124e4 ]
With CONFIG_DEBUG_TEST_DRIVER_REMOVE=y, a system would try to probe, unregister and probe again a driver.
When ghes_edac is attempted to be loaded on a system which is not on the safe platforms list, ghes_edac_register() would return early. The unregister counterpart ghes_edac_unregister() would still attempt to unregister and exit early at the refcount test, leading to the refcount underflow below.
In order to not do *anything* on the unregister path too, reuse the force_load parameter and check it on that path too, before fumbling with the refcount.
ghes_edac: ghes_edac_register: entry ghes_edac: ghes_edac_register: return -ENODEV ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 10 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0xb9/0x100 Modules linked in: CPU: 10 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4+ #12 Hardware name: GIGABYTE MZ01-CE1-00/MZ01-CE1-00, BIOS F02 08/29/2018 RIP: 0010:refcount_warn_saturate+0xb9/0x100 Code: 82 e8 fb 8f 4d 00 90 0f 0b 90 90 c3 80 3d 55 4c f5 00 00 75 88 c6 05 4c 4c f5 00 01 90 48 c7 c7 d0 8a 10 82 e8 d8 8f 4d 00 90 <0f> 0b 90 90 c3 80 3d 30 4c f5 00 00 0f 85 61 ff ff ff c6 05 23 4c RSP: 0018:ffffc90000037d58 EFLAGS: 00010292 RAX: 0000000000000026 RBX: ffff88840b8da000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff8216b24f RDI: 00000000ffffffff RBP: ffff88840c662e00 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000046 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88840ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000800002211000 CR4: 00000000003506e0 Call Trace: ghes_edac_unregister ghes_remove platform_drv_remove really_probe driver_probe_device device_driver_attach __driver_attach ? device_driver_attach ? device_driver_attach bus_for_each_dev bus_add_driver driver_register ? bert_init ghes_init do_one_initcall ? rcu_read_lock_sched_held kernel_init_freeable ? rest_init kernel_init ret_from_fork ... ghes_edac: ghes_edac_unregister: FALSE, refcount: -1073741824
Signed-off-by: Borislav Petkov bp@suse.de Link: https://lkml.kernel.org/r/20200911164950.GB19320@zn.tnic Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/edac/ghes_edac.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c index cb3dab56a875d..efad23575b16b 100644 --- a/drivers/edac/ghes_edac.c +++ b/drivers/edac/ghes_edac.c @@ -469,6 +469,7 @@ int ghes_edac_register(struct ghes *ghes, struct device *dev) if (!force_load && idx < 0) return -ENODEV; } else { + force_load = true; idx = 0; }
@@ -566,6 +567,9 @@ void ghes_edac_unregister(struct ghes *ghes) struct mem_ctl_info *mci; unsigned long flags;
+ if (!force_load) + return; + mutex_lock(&ghes_reg_mutex);
if (!refcount_dec_and_test(&ghes_refcount))
From: Dennis Li Dennis.Li@amd.com
[ Upstream commit 087d764159996ae378b08c0fdd557537adfd6899 ]
In the resume stage of GPU recovery, start_cpsch will call pm_init which set pm->allocated as false, cause the next pm_release_ib has no chance to release ib memory.
Add pm_release_ib in stop_cpsch which will be called in the suspend stage of GPU recovery.
Reviewed-by: Felix Kuehling Felix.Kuehling@amd.com Signed-off-by: Dennis Li Dennis.Li@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c index e9c4867abeffb..00b042a15373a 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c @@ -1177,6 +1177,8 @@ static int stop_cpsch(struct device_queue_manager *dqm) dqm->sched_running = false; dqm_unlock(dqm);
+ pm_release_ib(&dqm->packets); + kfd_gtt_sa_free(dqm->dev, dqm->fence_mem); pm_uninit(&dqm->packets, hanging);
From: Bhawanpreet Lakha Bhawanpreet.Lakha@amd.com
[ Upstream commit 4cdd7b332ed139b1e37faeb82409a14490adb644 ]
[Why] Previously we were only calling add_topology when hdcp was being enabled. Now we call add_topology by default so the ERROR messages are printed if the firmware is not loaded.
This error message is not relevant for normal display functionality so no need to print a ERROR message.
[How] Change DRM_ERROR to DRM_INFO
Signed-off-by: Bhawanpreet Lakha Bhawanpreet.Lakha@amd.com Acked-by: Aurabindo Pillai aurabindo.pillai@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c index fb1161dd7ea80..3a367a5968ae1 100644 --- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c +++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c @@ -88,7 +88,7 @@ enum mod_hdcp_status mod_hdcp_add_display_to_topology(struct mod_hdcp *hdcp, enum mod_hdcp_status status = MOD_HDCP_STATUS_SUCCESS;
if (!psp->dtm_context.dtm_initialized) { - DRM_ERROR("Failed to add display topology, DTM TA is not initialized."); + DRM_INFO("Failed to add display topology, DTM TA is not initialized."); display->state = MOD_HDCP_DISPLAY_INACTIVE; return MOD_HDCP_STATUS_FAILURE; }
From: Jun Lei jun.lei@amd.com
[ Upstream commit c4790a8894232f39c25c7c546c06efe074e63384 ]
[why] Recent characterization shows increased stutter latencies on some SKUs, leading to underflow.
[how] Update SOC params to account for this worst case latency.
Signed-off-by: Jun Lei jun.lei@amd.com Acked-by: Aurabindo Pillai aurabindo.pillai@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c index 2d9055eb3ce92..20bdabebbc434 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c @@ -409,8 +409,8 @@ struct _vcs_dpi_soc_bounding_box_st dcn2_0_nv14_soc = { }, }, .num_states = 5, - .sr_exit_time_us = 8.6, - .sr_enter_plus_exit_time_us = 10.9, + .sr_exit_time_us = 11.6, + .sr_enter_plus_exit_time_us = 13.9, .urgent_latency_us = 4.0, .urgent_latency_pixel_data_only_us = 4.0, .urgent_latency_pixel_mixed_with_vm_data_us = 4.0,
From: Michel Dänzer mdaenzer@redhat.com
[ Upstream commit 2f228aab21bbc74e90e267a721215ec8be51daf7 ]
Don't check drm_crtc_state::active for this either, per its documentation in include/drm/drm_crtc.h:
* Hence drivers must not consult @active in their various * &drm_mode_config_funcs.atomic_check callback to reject an atomic * commit.
atomic_remove_fb disables the CRTC as needed for disabling the primary plane.
This prevents at least the following problems if the primary plane gets disabled (e.g. due to destroying the FB assigned to the primary plane, as happens e.g. with mutter in Wayland mode):
* The legacy cursor ioctl returned EINVAL for a non-0 cursor FB ID (which enables the cursor plane). * If the cursor plane was enabled, changing the legacy DPMS property value from off to on returned EINVAL.
v2: * Minor changes to code comment and commit log, per review feedback.
GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1108 GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1165 GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1344 Suggested-by: Daniel Vetter daniel.vetter@ffwll.ch Acked-by: Daniel Vetter daniel.vetter@ffwll.ch Reviewed-by: Nicholas Kazlauskas nicholas.kazlauskas@amd.com Signed-off-by: Michel Dänzer mdaenzer@redhat.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 ++++++------------- 1 file changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 3f7eced92c0c8..7c1cc0ba30a55 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -5257,19 +5257,6 @@ static void dm_crtc_helper_disable(struct drm_crtc *crtc) { }
-static bool does_crtc_have_active_cursor(struct drm_crtc_state *new_crtc_state) -{ - struct drm_device *dev = new_crtc_state->crtc->dev; - struct drm_plane *plane; - - drm_for_each_plane_mask(plane, dev, new_crtc_state->plane_mask) { - if (plane->type == DRM_PLANE_TYPE_CURSOR) - return true; - } - - return false; -} - static int count_crtc_active_planes(struct drm_crtc_state *new_crtc_state) { struct drm_atomic_state *state = new_crtc_state->state; @@ -5349,19 +5336,20 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc *crtc, return ret; }
- /* In some use cases, like reset, no stream is attached */ - if (!dm_crtc_state->stream) - return 0; - /* - * We want at least one hardware plane enabled to use - * the stream with a cursor enabled. + * We require the primary plane to be enabled whenever the CRTC is, otherwise + * drm_mode_cursor_universal may end up trying to enable the cursor plane while all other + * planes are disabled, which is not supported by the hardware. And there is legacy + * userspace which stops using the HW cursor altogether in response to the resulting EINVAL. */ - if (state->enable && state->active && - does_crtc_have_active_cursor(state) && - dm_crtc_state->active_planes == 0) + if (state->enable && + !(state->plane_mask & drm_plane_mask(crtc->primary))) return -EINVAL;
+ /* In some use cases, like reset, no stream is attached */ + if (!dm_crtc_state->stream) + return 0; + if (dc_validate_stream(dc, dm_crtc_state->stream) == DC_OK) return 0;
From: Bhawanpreet Lakha Bhawanpreet.Lakha@amd.com
[ Upstream commit 875d369d8f75275d30e59421602d9366426abff7 ]
[Why] DTM topology updates happens by default now. This results in DTM warnings when hdcp is not even being enabled. This spams the dmesg and doesn't effect normal display functionality so it is better to log it using DRM_DEBUG_KMS()
[How] Change the DRM_WARN() to DRM_DEBUG_KMS()
Signed-off-by: Bhawanpreet Lakha Bhawanpreet.Lakha@amd.com Acked-by: Alex Deucher alexander.deucher@amd.com Reviewed-by: Rodrigo Siqueira Rodrigo.Siqueira@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h index d3192b9d0c3d8..47f8ee2832ff0 100644 --- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h +++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h @@ -27,7 +27,7 @@ #define MOD_HDCP_LOG_H_
#ifdef CONFIG_DRM_AMD_DC_HDCP -#define HDCP_LOG_ERR(hdcp, ...) DRM_WARN(__VA_ARGS__) +#define HDCP_LOG_ERR(hdcp, ...) DRM_DEBUG_KMS(__VA_ARGS__) #define HDCP_LOG_VER(hdcp, ...) DRM_DEBUG_KMS(__VA_ARGS__) #define HDCP_LOG_FSM(hdcp, ...) DRM_DEBUG_KMS(__VA_ARGS__) #define HDCP_LOG_TOP(hdcp, ...) pr_debug("[HDCP_TOP]:"__VA_ARGS__)
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit 21653a4181ff292480599dad996a2b759ccf050f ]
Some ACPI i2c-devices _STA method (which is used to detect if the device is present) use autodetection code which probes which device is present over i2c. This requires the I2C ACPI OpRegion handler to be registered before we enumerate i2c-clients under the i2c-adapter.
This fixes the i2c touchpad on the Lenovo ThinkBook 14-IIL and ThinkBook 15 IIL not getting an i2c-client instantiated and thus not working.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1842039 Signed-off-by: Hans de Goede hdegoede@redhat.com Reviewed-by: Mika Westerberg mika.westerberg@linux.intel.com Signed-off-by: Wolfram Sang wsa@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/i2c/i2c-core-base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 4f09d4c318287..7031393c74806 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -1336,8 +1336,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
/* create pre-declared device nodes */ of_i2c_register_devices(adap); - i2c_acpi_register_devices(adap); i2c_acpi_install_space_handler(adap); + i2c_acpi_register_devices(adap);
if (adap->nr < __i2c_first_dynamic_bus_num) i2c_scan_static_board_info(adap);
Hi Hans, Sasha,
As mentioned on https://github.com/linux-surface/kernel/issues/63, I'm afraid I've bisected a boot time issue on the Microsoft Surface Go 2 to this commit on the stable 5.8 tree.
The effect as reported there is that the boot process stalls just after loading the usbhid module.
Typing, or interacting with the Keyboard (Type Cover) at that point appears to cause usb bus resets, but I don't know if that's a related symptom or just an effect of some underlying root cause.
I have been running a linux-media kernel on this device without issue.
Is this commit in 5.9? I'll build a vanilla v5.9 kernel and see if it occurs there too.
-- Regards
Kieran
On 21/09/2020 15:40, Sasha Levin wrote:
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit 21653a4181ff292480599dad996a2b759ccf050f ]
Some ACPI i2c-devices _STA method (which is used to detect if the device is present) use autodetection code which probes which device is present over i2c. This requires the I2C ACPI OpRegion handler to be registered before we enumerate i2c-clients under the i2c-adapter.
This fixes the i2c touchpad on the Lenovo ThinkBook 14-IIL and ThinkBook 15 IIL not getting an i2c-client instantiated and thus not working.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1842039 Signed-off-by: Hans de Goede hdegoede@redhat.com Reviewed-by: Mika Westerberg mika.westerberg@linux.intel.com Signed-off-by: Wolfram Sang wsa@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
drivers/i2c/i2c-core-base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 4f09d4c318287..7031393c74806 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -1336,8 +1336,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) /* create pre-declared device nodes */ of_i2c_register_devices(adap);
- i2c_acpi_register_devices(adap); i2c_acpi_install_space_handler(adap);
- i2c_acpi_register_devices(adap);
if (adap->nr < __i2c_first_dynamic_bus_num) i2c_scan_static_board_info(adap);
Hi,
On 10/14/20 1:09 PM, Kieran Bingham wrote:
Hi Hans, Sasha,
As mentioned on https://github.com/linux-surface/kernel/issues/63, I'm afraid I've bisected a boot time issue on the Microsoft Surface Go 2 to this commit on the stable 5.8 tree.
The effect as reported there is that the boot process stalls just after loading the usbhid module.
Typing, or interacting with the Keyboard (Type Cover) at that point appears to cause usb bus resets, but I don't know if that's a related symptom or just an effect of some underlying root cause.
I have been running a linux-media kernel on this device without issue.
Is this commit in 5.9? I'll build a vanilla v5.9 kernel and see if it occurs there too.
Yes the commit is in 5.9 too. Still would be interesting to see if 5.9 hits this issue too. I guess it will, but as I mentioned in:
https://github.com/linux-surface/kernel/issues/63
I do not understand why this commit is causing this issue.
So I just checked and the whole acpidump is not using I2C opregion stuff at all:
[hans@x1 microsoft-surface-go2]$ ack GenericSerialBus *.dsl [hans@x1 microsoft-surface-go2]$
And there is only 1 _REG handler which is for the embedded-controller.
So this patch should not make a difference at all on the GO2, other then maybe a subtle timing difference somewhere ... ?
Regards,
Hans
On 21/09/2020 15:40, Sasha Levin wrote:
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit 21653a4181ff292480599dad996a2b759ccf050f ]
Some ACPI i2c-devices _STA method (which is used to detect if the device is present) use autodetection code which probes which device is present over i2c. This requires the I2C ACPI OpRegion handler to be registered before we enumerate i2c-clients under the i2c-adapter.
This fixes the i2c touchpad on the Lenovo ThinkBook 14-IIL and ThinkBook 15 IIL not getting an i2c-client instantiated and thus not working.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1842039 Signed-off-by: Hans de Goede hdegoede@redhat.com Reviewed-by: Mika Westerberg mika.westerberg@linux.intel.com Signed-off-by: Wolfram Sang wsa@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
drivers/i2c/i2c-core-base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 4f09d4c318287..7031393c74806 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -1336,8 +1336,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) /* create pre-declared device nodes */ of_i2c_register_devices(adap);
- i2c_acpi_register_devices(adap); i2c_acpi_install_space_handler(adap);
- i2c_acpi_register_devices(adap);
if (adap->nr < __i2c_first_dynamic_bus_num) i2c_scan_static_board_info(adap);
Hi Hans,
On 14/10/2020 12:23, Hans de Goede wrote:
Hi,
On 10/14/20 1:09 PM, Kieran Bingham wrote:
Hi Hans, Sasha,
As mentioned on https://github.com/linux-surface/kernel/issues/63, I'm afraid I've bisected a boot time issue on the Microsoft Surface Go 2 to this commit on the stable 5.8 tree.
The effect as reported there is that the boot process stalls just after loading the usbhid module.
Typing, or interacting with the Keyboard (Type Cover) at that point appears to cause usb bus resets, but I don't know if that's a related symptom or just an effect of some underlying root cause.
I have been running a linux-media kernel on this device without issue.
Is this commit in 5.9? I'll build a vanilla v5.9 kernel and see if it occurs there too.
Yes the commit is in 5.9 too. Still would be interesting to see if 5.9 hits this issue too. I guess it will, but as I mentioned in:
Indeed, I've just tested vanilla 5.9 on a Surface Go 2 and that's broken I'm afraid.
Back traces on 5.9 [0] show hung tasks on both the i915_driver_probe, and the tps68470_gpio_probe. I suspect the i915 failure of course is the reason a desktop environment can't be reached, however I was able to ssh in at least ;-)
[0] https://paste.debian.net/1167081/
Given that this is now a mainline bug, I'll reply to the mainline patch and suggest a revert there, rather than here on the stable patches.
As for fixing it ... I don't have enough visibility of the problem for both this, and the issues that were fixed by this patch.
Let me know if there's anything you'd like me to investigate further, or dig into specifically.
-- Kieran
https://github.com/linux-surface/kernel/issues/63
I do not understand why this commit is causing this issue.
So I just checked and the whole acpidump is not using I2C opregion stuff at all:
[hans@x1 microsoft-surface-go2]$ ack GenericSerialBus *.dsl [hans@x1 microsoft-surface-go2]$
And there is only 1 _REG handler which is for the embedded-controller.
So this patch should not make a difference at all on the GO2, other then maybe a subtle timing difference somewhere ... ?
Regards,
Hans
On 21/09/2020 15:40, Sasha Levin wrote:
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit 21653a4181ff292480599dad996a2b759ccf050f ]
Some ACPI i2c-devices _STA method (which is used to detect if the device is present) use autodetection code which probes which device is present over i2c. This requires the I2C ACPI OpRegion handler to be registered before we enumerate i2c-clients under the i2c-adapter.
This fixes the i2c touchpad on the Lenovo ThinkBook 14-IIL and ThinkBook 15 IIL not getting an i2c-client instantiated and thus not working.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1842039 Signed-off-by: Hans de Goede hdegoede@redhat.com Reviewed-by: Mika Westerberg mika.westerberg@linux.intel.com Signed-off-by: Wolfram Sang wsa@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
drivers/i2c/i2c-core-base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 4f09d4c318287..7031393c74806 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -1336,8 +1336,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) /* create pre-declared device nodes */ of_i2c_register_devices(adap); - i2c_acpi_register_devices(adap); i2c_acpi_install_space_handler(adap); + i2c_acpi_register_devices(adap); if (adap->nr < __i2c_first_dynamic_bus_num) i2c_scan_static_board_info(adap);
Hi all,
On 10/14/20 1:23 PM, Hans de Goede wrote:
Hi,
On 10/14/20 1:09 PM, Kieran Bingham wrote:
Hi Hans, Sasha,
As mentioned on https://github.com/linux-surface/kernel/issues/63, I'm afraid I've bisected a boot time issue on the Microsoft Surface Go 2 to this commit on the stable 5.8 tree.
The effect as reported there is that the boot process stalls just after loading the usbhid module.
Typing, or interacting with the Keyboard (Type Cover) at that point appears to cause usb bus resets, but I don't know if that's a related symptom or just an effect of some underlying root cause.
I have been running a linux-media kernel on this device without issue.
Is this commit in 5.9? I'll build a vanilla v5.9 kernel and see if it occurs there too.
Yes the commit is in 5.9 too. Still would be interesting to see if 5.9 hits this issue too. I guess it will, but as I mentioned in:
https://github.com/linux-surface/kernel/issues/63
I do not understand why this commit is causing this issue.
So I just checked and the whole acpidump is not using I2C opregion stuff at all:
[hans@x1 microsoft-surface-go2]$ ack GenericSerialBus *.dsl [hans@x1 microsoft-surface-go2]$
And there is only 1 _REG handler which is for the embedded-controller.
So this patch should not make a difference at all on the GO2, other then maybe a subtle timing difference somewhere ... ?
Thanks to Maximilian Luz sharp eyes this is explained now, despite the name of the i2c_acpi_install_space_handler() it also had a acpi_walk_dep_device_list() call hidden in there, so the "i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices()" also moved that acpi_walk_dep_device_list() earlier.
I've given Kieran a patch to test which in essence reverts the part where the acpi_walk_dep_device_list() call is also moved earlier and that fixes the Surface Go 2 not booting.
I will submit this fix upstream right away and I'll also send a separate mail to Greg / stable@vger to see if Greg is willing to make an exception and at this to the stable series before it hits Linus' tree.
Regards,
Hans
From: Josh Poimboeuf jpoimboe@redhat.com
[ Upstream commit db6c6a0df840e3f52c84cc302cc1a08ba11a4416 ]
When a function is annotated with STACK_FRAME_NON_STANDARD, objtool doesn't validate its code paths. It also skips sibling call detection within the function.
But sibling call detection is actually needed for the case where the ignored function doesn't have any return instructions. Otherwise objtool naively marks the function as implicit static noreturn, which affects the reachability of its callers, resulting in "unreachable instruction" warnings.
Fix it by just enabling sibling call detection for ignored functions. The 'insn->ignore' check in add_jump_destinations() is no longer needed after
e6da9567959e ("objtool: Don't use ignore flag for fake jumps").
Fixes the following warning:
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_handle_exit_irqoff()+0x142: unreachable instruction
which triggers on an allmodconfig with CONFIG_GCOV_KERNEL unset.
Reported-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com Signed-off-by: Borislav Petkov bp@suse.de Acked-by: Linus Torvalds torvalds@linux-foundation.org Link: https://lkml.kernel.org/r/5b1e2536cdbaa5246b60d7791b76130a74082c62.159975146... Signed-off-by: Sasha Levin sashal@kernel.org --- tools/objtool/check.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 5e0d70a89fb87..773e6c7ee5f93 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -619,7 +619,7 @@ static int add_jump_destinations(struct objtool_file *file) if (!is_static_jump(insn)) continue;
- if (insn->ignore || insn->offset == FAKE_JUMP_OFFSET) + if (insn->offset == FAKE_JUMP_OFFSET) continue;
rela = find_rela_by_dest_range(file->elf, insn->sec,
From: Qii Wang qii.wang@mediatek.com
[ Upstream commit b44658e755b5a733e9df04449facbc738df09170 ]
The master code needs to being sent when the speed is more than I2C_MAX_FAST_MODE_PLUS_FREQ, not I2C_MAX_FAST_MODE_FREQ in the latest I2C-bus specification and user manual.
Signed-off-by: Qii Wang qii.wang@mediatek.com Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Signed-off-by: Wolfram Sang wsa@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/i2c/busses/i2c-mt65xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index deef69e569062..440b12eba1e3c 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -736,7 +736,7 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk) for (clk_div = 1; clk_div <= max_clk_div; clk_div++) { clk_src = parent_clk / clk_div;
- if (target_speed > I2C_MAX_FAST_MODE_FREQ) { + if (target_speed > I2C_MAX_FAST_MODE_PLUS_FREQ) { /* Set master code speed register */ ret = mtk_i2c_calculate_speed(i2c, clk_src, I2C_MAX_FAST_MODE_FREQ,
From: Damien Le Moal damien.lemoal@wdc.com
[ Upstream commit f025d9d9934b84cd03b7796072d10686029c408e ]
The Kendryte K210 SoC CLINT is compatible with Sifive clint v0 (sifive,clint0). Fix the Kendryte K210 device tree clint entry to be inline with the sifive timer definition documented in Documentation/devicetree/bindings/timer/sifive,clint.yaml. The device tree clint entry is renamed similarly to u-boot device tree definition to improve compatibility with u-boot defined device tree. To ensure correct initialization, the interrup-cells attribute is added and the interrupt-extended attribute definition fixed.
This fixes boot failures with Kendryte K210 SoC boards.
Note that the clock referenced is kept as K210_CLK_ACLK, which does not necessarilly match the clint MTIME increment rate. This however does not seem to cause any problem for now.
Signed-off-by: Damien Le Moal damien.lemoal@wdc.com Signed-off-by: Palmer Dabbelt palmerdabbelt@google.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/riscv/boot/dts/kendryte/k210.dtsi | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/boot/dts/kendryte/k210.dtsi b/arch/riscv/boot/dts/kendryte/k210.dtsi index c1df56ccb8d55..d2d0ff6456325 100644 --- a/arch/riscv/boot/dts/kendryte/k210.dtsi +++ b/arch/riscv/boot/dts/kendryte/k210.dtsi @@ -95,10 +95,12 @@ sysctl: sysctl@50440000 { #clock-cells = <1>; };
- clint0: interrupt-controller@2000000 { + clint0: clint@2000000 { + #interrupt-cells = <1>; compatible = "riscv,clint0"; reg = <0x2000000 0xC000>; - interrupts-extended = <&cpu0_intc 3>, <&cpu1_intc 3>; + interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7 + &cpu1_intc 3 &cpu1_intc 7>; clocks = <&sysctl K210_CLK_ACLK>; };
On 2020/09/21 23:41, Sasha Levin wrote:
From: Damien Le Moal damien.lemoal@wdc.com
[ Upstream commit f025d9d9934b84cd03b7796072d10686029c408e ]
The Kendryte K210 SoC CLINT is compatible with Sifive clint v0 (sifive,clint0). Fix the Kendryte K210 device tree clint entry to be inline with the sifive timer definition documented in Documentation/devicetree/bindings/timer/sifive,clint.yaml. The device tree clint entry is renamed similarly to u-boot device tree definition to improve compatibility with u-boot defined device tree. To ensure correct initialization, the interrup-cells attribute is added and the interrupt-extended attribute definition fixed.
This fixes boot failures with Kendryte K210 SoC boards.
Note that the clock referenced is kept as K210_CLK_ACLK, which does not necessarilly match the clint MTIME increment rate. This however does not seem to cause any problem for now.
Signed-off-by: Damien Le Moal damien.lemoal@wdc.com Signed-off-by: Palmer Dabbelt palmerdabbelt@google.com Signed-off-by: Sasha Levin sashal@kernel.org
arch/riscv/boot/dts/kendryte/k210.dtsi | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/boot/dts/kendryte/k210.dtsi b/arch/riscv/boot/dts/kendryte/k210.dtsi index c1df56ccb8d55..d2d0ff6456325 100644 --- a/arch/riscv/boot/dts/kendryte/k210.dtsi +++ b/arch/riscv/boot/dts/kendryte/k210.dtsi @@ -95,10 +95,12 @@ sysctl: sysctl@50440000 { #clock-cells = <1>; };
clint0: interrupt-controller@2000000 {
clint0: clint@2000000 {#interrupt-cells = <1>; compatible = "riscv,clint0"; reg = <0x2000000 0xC000>;
interrupts-extended = <&cpu0_intc 3>, <&cpu1_intc 3>;
interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7&cpu1_intc 3 &cpu1_intc 7>; clocks = <&sysctl K210_CLK_ACLK>;
Sasha,
This is a fix for a problem in 5.9 tree. 5.8 kernel is fine without this patch. And I think applying it to 5.8 might actually break things since the proper clint driver was added to kernel 5.9 and does not exist in 5.8.
Best regards.
On Tue, 22 Sep 2020 17:27:42 PDT (-0700), Damien Le Moal wrote:
On 2020/09/21 23:41, Sasha Levin wrote: From: Damien Le Moal damien.lemoal@wdc.com
[ Upstream commit f025d9d9934b84cd03b7796072d10686029c408e ]
The Kendryte K210 SoC CLINT is compatible with Sifive clint v0 (sifive,clint0). Fix the Kendryte K210 device tree clint entry to be inline with the sifive timer definition documented in Documentation/devicetree/bindings/timer/sifive,clint.yaml. The device tree clint entry is renamed similarly to u-boot device tree definition to improve compatibility with u-boot defined device tree. To ensure correct initialization, the interrup-cells attribute is added and the interrupt-extended attribute definition fixed.
This fixes boot failures with Kendryte K210 SoC boards.
Note that the clock referenced is kept as K210_CLK_ACLK, which does not necessarilly match the clint MTIME increment rate. This however does not seem to cause any problem for now.
Signed-off-by: Damien Le Moal damien.lemoal@wdc.com Signed-off-by: Palmer Dabbelt palmerdabbelt@google.com Signed-off-by: Sasha Levin sashal@kernel.org
arch/riscv/boot/dts/kendryte/k210.dtsi | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/boot/dts/kendryte/k210.dtsi b/arch/riscv/boot/dts/kendryte/k210.dtsi index c1df56ccb8d55..d2d0ff6456325 100644 --- a/arch/riscv/boot/dts/kendryte/k210.dtsi +++ b/arch/riscv/boot/dts/kendryte/k210.dtsi @@ -95,10 +95,12 @@ sysctl: sysctl@50440000 { #clock-cells = <1>; };
clint0: interrupt-controller@2000000 {
clint0: clint@2000000 {#interrupt-cells = <1>; compatible = "riscv,clint0"; reg = <0x2000000 0xC000>;
interrupts-extended = <&cpu0_intc 3>, <&cpu1_intc 3>;
interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7&cpu1_intc 3 &cpu1_intc 7>; clocks = <&sysctl K210_CLK_ACLK>;Sasha,
This is a fix for a problem in 5.9 tree. 5.8 kernel is fine without this patch. And I think applying it to 5.8 might actually break things since the proper clint driver was added to kernel 5.9 and does not exist in 5.8.
IIUC this won't actually break anything on 5.8, as the reason nobody noticed that the old one was broken is because the old CLINT driver just didn't care about what's in the device tree. These interrupt numbers are defined by the ISA manual so we jut had them encoded into the arch/riscv first-level interrupt controller driver.
That said, it definately doesn't fix anything so it seems safer to just not backport it.
On Sat, Sep 26, 2020 at 12:42:42PM -0700, Palmer Dabbelt wrote:
On Tue, 22 Sep 2020 17:27:42 PDT (-0700), Damien Le Moal wrote:
On 2020/09/21 23:41, Sasha Levin wrote: From: Damien Le Moal damien.lemoal@wdc.com
[ Upstream commit f025d9d9934b84cd03b7796072d10686029c408e ]
The Kendryte K210 SoC CLINT is compatible with Sifive clint v0 (sifive,clint0). Fix the Kendryte K210 device tree clint entry to be inline with the sifive timer definition documented in Documentation/devicetree/bindings/timer/sifive,clint.yaml. The device tree clint entry is renamed similarly to u-boot device tree definition to improve compatibility with u-boot defined device tree. To ensure correct initialization, the interrup-cells attribute is added and the interrupt-extended attribute definition fixed.
This fixes boot failures with Kendryte K210 SoC boards.
Note that the clock referenced is kept as K210_CLK_ACLK, which does not necessarilly match the clint MTIME increment rate. This however does not seem to cause any problem for now.
Signed-off-by: Damien Le Moal damien.lemoal@wdc.com Signed-off-by: Palmer Dabbelt palmerdabbelt@google.com Signed-off-by: Sasha Levin sashal@kernel.org
arch/riscv/boot/dts/kendryte/k210.dtsi | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/boot/dts/kendryte/k210.dtsi b/arch/riscv/boot/dts/kendryte/k210.dtsi index c1df56ccb8d55..d2d0ff6456325 100644 --- a/arch/riscv/boot/dts/kendryte/k210.dtsi +++ b/arch/riscv/boot/dts/kendryte/k210.dtsi @@ -95,10 +95,12 @@ sysctl: sysctl@50440000 { #clock-cells = <1>; };
clint0: interrupt-controller@2000000 {
clint0: clint@2000000 {#interrupt-cells = <1>; compatible = "riscv,clint0"; reg = <0x2000000 0xC000>;
interrupts-extended = <&cpu0_intc 3>, <&cpu1_intc 3>;
interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7&cpu1_intc 3 &cpu1_intc 7>; clocks = <&sysctl K210_CLK_ACLK>;Sasha,
This is a fix for a problem in 5.9 tree. 5.8 kernel is fine without this patch. And I think applying it to 5.8 might actually break things since the proper clint driver was added to kernel 5.9 and does not exist in 5.8.
IIUC this won't actually break anything on 5.8, as the reason nobody noticed that the old one was broken is because the old CLINT driver just didn't care about what's in the device tree. These interrupt numbers are defined by the ISA manual so we jut had them encoded into the arch/riscv first-level interrupt controller driver.
That said, it definately doesn't fix anything so it seems safer to just not backport it.
Sure, I'll drop it. Thanks!
linux-stable-mirror@lists.linaro.org
-
Damien Le Moal -
Hans de Goede -
Kieran Bingham -
Mark Brown -
Palmer Dabbelt -
Sasha Levin