From: Amol Grover <[email protected]>
[ 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 <[email protected]>
Signed-off-by: James Morris <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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))
--
2.25.1
From: Hans de Goede <[email protected]>
[ 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 <[email protected]>
Acked-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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 = {
--
2.25.1
From: Sylwester Nawrocki <[email protected]>
[ 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 <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Charles Keepax <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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);
--
2.25.1
From: Qii Wang <[email protected]>
[ 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 <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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,
--
2.25.1
From: Bhawanpreet Lakha <[email protected]>
[ 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 <[email protected]>
Acked-by: Aurabindo Pillai <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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;
}
--
2.25.1
From: Eddie James <[email protected]>
[ 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 <[email protected]>
Reviewed-by: Tao Ren <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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)
--
2.25.1
From: Palmer Dabbelt <[email protected]>
[ 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 <[email protected]>
Acked-by: Guo Ren <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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,
--
2.25.1
From: Josh Poimboeuf <[email protected]>
[ 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 <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Linus Torvalds <[email protected]>
Link: https://lkml.kernel.org/r/5b1e2536cdbaa5246b60d7791b76130a74082c62.1599751464.git.jpoimboe@redhat.com
Signed-off-by: Sasha Levin <[email protected]>
---
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,
--
2.25.1
From: Sylwester Nawrocki <[email protected]>
[ 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 <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Charles Keepax <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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;
--
2.25.1
From: Bhawanpreet Lakha <[email protected]>
[ 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 <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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__)
--
2.25.1
From: Hans de Goede <[email protected]>
[ 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 <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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);
--
2.25.1
From: Jun Lei <[email protected]>
[ 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 <[email protected]>
Acked-by: Aurabindo Pillai <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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,
--
2.25.1
From: Ilya Leoshkevich <[email protected]>
[ 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 <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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)
--
2.25.1
From: Sumera Priyadarsini <[email protected]>
[ 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 <[email protected]>
Link: https://lore.kernel.org/r/20200829175704.GA10998@Kaladin
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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;
--
2.25.1
From: Dennis Li <[email protected]>
[ 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 <[email protected]>
Signed-off-by: Dennis Li <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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);
--
2.25.1
From: Kuninori Morimoto <[email protected]>
[ 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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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;
--
2.25.1
From: Michel Dänzer <[email protected]>
[ 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 <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Reviewed-by: Nicholas Kazlauskas <[email protected]>
Signed-off-by: Michel Dänzer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
.../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;
--
2.25.1
From: Damien Le Moal <[email protected]>
[ 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 <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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>;
};
--
2.25.1
From: Sven Schnelle <[email protected]>
[ Upstream commit 73ac74c7d489756d2313219a108809921dbfaea1 ]
Switch order so that locking state is consistent even
if the IRQ tracer calls into lockdep again.
Acked-by: Peter Zijlstra <[email protected]>
Signed-off-by: Sven Schnelle <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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);
--
2.25.1
From: Borislav Petkov <[email protected]>
[ 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 <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
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))
--
2.25.1
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.
--
Thanks,
Sasha
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!
--
Thanks,
Sasha
On 2020/09/21 23:41, Sasha Levin wrote:
> From: Damien Le Moal <[email protected]>
>
> [ 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 <[email protected]>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> ---
> 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.
--
Damien Le Moal
Western Digital Research
>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 <[email protected]>
>>
>> [ 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 <[email protected]>
>> Signed-off-by: Palmer Dabbelt <[email protected]>
>> Signed-off-by: Sasha Levin <[email protected]>
>> ---
>> 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 <[email protected]>
>>>
>>>[ 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 <[email protected]>
>>>Signed-off-by: Palmer Dabbelt <[email protected]>
>>>Signed-off-by: Sasha Levin <[email protected]>
>>>---
>>> 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!
--
Thanks,
Sasha
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 <[email protected]>
>>
>> [ 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 <[email protected]>
>> Reviewed-by: Mika Westerberg <[email protected]>
>> Signed-off-by: Wolfram Sang <[email protected]>
>> Signed-off-by: Sasha Levin <[email protected]>
>> ---
>> 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
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 <[email protected]>
>
> [ 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 <[email protected]>
> Reviewed-by: Mika Westerberg <[email protected]>
> Signed-off-by: Wolfram Sang <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> ---
> 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);
>
--
Regards
--
Kieran
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 <[email protected]>
>>>
>>> [ 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 <[email protected]>
>>> Reviewed-by: Mika Westerberg <[email protected]>
>>> Signed-off-by: Wolfram Sang <[email protected]>
>>> Signed-off-by: Sasha Levin <[email protected]>
>>> ---
>>> 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);
>>>
>>
>>
>
--
Regards
--
Kieran