From: Arvid Norlander lkml@vorpal.se
[ Upstream commit 574160b8548deff8b80b174f03201e94ab8431e2 ]
Toshiba Satellite Z830 needs the quirk video_disable_backlight_sysfs_if for proper backlight control after suspend/resume cycles.
Toshiba Portege Z830 is simply the same laptop rebranded for certain markets (I looked through the manual to other language sections to confirm this) and thus also needs this quirk.
Thanks to Hans de Goede for suggesting this fix.
Link: https://www.spinics.net/lists/platform-driver-x86/msg34394.html Suggested-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Arvid Norlander lkml@vorpal.se Reviewed-by: Hans de Goede hdegoede@redhat.com Tested-by: Arvid Norlander lkml@vorpal.se Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/acpi/acpi_video.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index ea0573176894..209903c2ee85 100644 --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -485,6 +485,22 @@ static struct dmi_system_id video_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "SATELLITE R830"), }, }, + { + .callback = video_disable_backlight_sysfs_if, + .ident = "Toshiba Satellite Z830", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), + DMI_MATCH(DMI_PRODUCT_NAME, "SATELLITE Z830"), + }, + }, + { + .callback = video_disable_backlight_sysfs_if, + .ident = "Toshiba Portege Z830", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), + DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE Z830"), + }, + }, /* * Some machine's _DOD IDs don't have bit 31(Device ID Scheme) set * but the IDs actually follow the Device ID Scheme.
From: Kees Cook keescook@chromium.org
[ Upstream commit 0dedcf6e3301836eb70cfa649052e7ce4fcd13ba ]
Clang is especially sensitive about argument type matching when using __overloaded functions (like memcmp(), etc). Help it see that function pointers are just "void *". Avoids this error:
arch/mips/bcm47xx/prom.c:89:8: error: no matching function for call to 'memcmp' if (!memcmp(prom_init, prom_init + mem, 32)) ^~~~~~ include/linux/string.h:156:12: note: candidate function not viable: no known conversion from 'void (void)' to 'const void *' for 1st argument extern int memcmp(const void *,const void *,__kernel_size_t);
Cc: Hauke Mehrtens hauke@hauke-m.de Cc: "Rafał Miłecki" zajec5@gmail.com Cc: Thomas Bogendoerfer tsbogend@alpha.franken.de Cc: linux-mips@vger.kernel.org Cc: Nathan Chancellor nathan@kernel.org Cc: Nick Desaulniers ndesaulniers@google.com Cc: llvm@lists.linux.dev Reported-by: kernel test robot lkp@intel.com Link: https://lore.kernel.org/lkml/202209080652.sz2d68e5-lkp@intel.com Signed-off-by: Kees Cook keescook@chromium.org Signed-off-by: Thomas Bogendoerfer tsbogend@alpha.franken.de Signed-off-by: Sasha Levin sashal@kernel.org --- arch/mips/bcm47xx/prom.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/bcm47xx/prom.c b/arch/mips/bcm47xx/prom.c index 135a5407f015..d26d9a6f6ee7 100644 --- a/arch/mips/bcm47xx/prom.c +++ b/arch/mips/bcm47xx/prom.c @@ -85,7 +85,7 @@ static __init void prom_init_mem(void) pr_debug("Assume 128MB RAM\n"); break; } - if (!memcmp(prom_init, prom_init + mem, 32)) + if (!memcmp((void *)prom_init, (void *)prom_init + mem, 32)) break; } lowmem = mem; @@ -162,7 +162,7 @@ void __init bcm47xx_prom_highmem_init(void)
off = EXTVBASE + __pa(off); for (extmem = 128 << 20; extmem < 512 << 20; extmem <<= 1) { - if (!memcmp(prom_init, (void *)(off + extmem), 16)) + if (!memcmp((void *)prom_init, (void *)(off + extmem), 16)) break; } extmem -= lowmem;
From: Chao Qin chao.qin@intel.com
[ Upstream commit 2d93540014387d1c73b9ccc4d7895320df66d01b ]
When value < time_unit, the parameter of ilog2() will be zero and the return value is -1. u64(-1) is too large for shift exponent and then will trigger shift-out-of-bounds:
shift exponent 18446744073709551615 is too large for 32-bit type 'int' Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us
Signed-off-by: Chao Qin chao.qin@intel.com Acked-by: Zhang Rui rui.zhang@intel.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/powercap/intel_rapl.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c index 8809c1a20bed..5f31606e1982 100644 --- a/drivers/powercap/intel_rapl.c +++ b/drivers/powercap/intel_rapl.c @@ -1080,6 +1080,9 @@ static u64 rapl_compute_time_window_core(struct rapl_package *rp, u64 value, y = value & 0x1f; value = (1 << y) * (4 + f) * rp->time_unit / 4; } else { + if (value < rp->time_unit) + return 0; + do_div(value, rp->time_unit); y = ilog2(value); f = div64_u64(4 * (value - (1 << y)), 1 << y);
From: Srinivas Pandruvada srinivas.pandruvada@linux.intel.com
[ Upstream commit 68b99e94a4a2db6ba9b31fe0485e057b9354a640 ]
When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ...
Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
Suggested-by: Chen Yu yu.c.chen@intel.com Signed-off-by: Srinivas Pandruvada srinivas.pandruvada@linux.intel.com [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/thermal/intel_powerclamp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/intel_powerclamp.c b/drivers/thermal/intel_powerclamp.c index afada655f861..492bb3ec6546 100644 --- a/drivers/thermal/intel_powerclamp.c +++ b/drivers/thermal/intel_powerclamp.c @@ -519,8 +519,10 @@ static int start_power_clamp(void)
/* prefer BSP */ control_cpu = 0; - if (!cpu_online(control_cpu)) - control_cpu = smp_processor_id(); + if (!cpu_online(control_cpu)) { + control_cpu = get_cpu(); + put_cpu(); + }
clamping = true; schedule_delayed_work(&poll_pkg_cstate_work, 0);
Hi!
From: Srinivas Pandruvada srinivas.pandruvada@linux.intel.com
[ Upstream commit 68b99e94a4a2db6ba9b31fe0485e057b9354a640 ]
When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace:
<TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ...
Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
This has exactly the same problem as smp_processor_id(), you just worked around the warning. If it is okay that control_cpu contains stale value, could we have a comment explaining why?
Thanks, Pavel
+++ b/drivers/thermal/intel_powerclamp.c @@ -519,8 +519,10 @@ static int start_power_clamp(void) /* prefer BSP */ control_cpu = 0;
- if (!cpu_online(control_cpu))
control_cpu = smp_processor_id();
- if (!cpu_online(control_cpu)) {
control_cpu = get_cpu();put_cpu();- }
clamping = true; schedule_delayed_work(&poll_pkg_cstate_work, 0); -- 2.35.1
Hi Pavel, On 2022-10-11 at 13:36:46 +0200, Pavel Machek wrote:
Hi!
From: Srinivas Pandruvada srinivas.pandruvada@linux.intel.com
[ Upstream commit 68b99e94a4a2db6ba9b31fe0485e057b9354a640 ]
When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace:
<TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ...
Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
This has exactly the same problem as smp_processor_id(), you just worked around the warning. If it is okay that control_cpu contains stale value, could we have a comment explaining why?
May I know why does control_cpu have stale value? The control_cpu is a random picked online CPU which will be used later to collect statistics. As long as the control_cpu is online, it is valid IMO.
thanks, Chenyu
Thanks, Pavel
+++ b/drivers/thermal/intel_powerclamp.c @@ -519,8 +519,10 @@ static int start_power_clamp(void) /* prefer BSP */ control_cpu = 0;
- if (!cpu_online(control_cpu))
control_cpu = smp_processor_id();
- if (!cpu_online(control_cpu)) {
control_cpu = get_cpu();put_cpu();- }
clamping = true; schedule_delayed_work(&poll_pkg_cstate_work, 0); -- 2.35.1
-- People of Russia, stop Putin before his war on Ukraine escalates.
On Tue, 2022-10-11 at 21:22 +0800, Chen Yu wrote:
Hi Pavel, On 2022-10-11 at 13:36:46 +0200, Pavel Machek wrote:
Hi!
From: Srinivas Pandruvada srinivas.pandruvada@linux.intel.com
[ Upstream commit 68b99e94a4a2db6ba9b31fe0485e057b9354a640 ]
When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace:
<TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ...
Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
This has exactly the same problem as smp_processor_id(), you just worked around the warning. If it is okay that control_cpu contains stale value, could we have a comment explaining why?
May I know why does control_cpu have stale value? The control_cpu is a random picked online CPU which will be used later to collect statistics. As long as the control_cpu is online, it is valid IMO.
I am also interested to know why this can be stale. The get_cpu() call disables preemption.
#define get_cpu() ({ preempt_disable(); __smp_processor_id(); })
Even if you change it to call debug_smp_processor_id() instead of __smp_processor_id(), it will still not print warning as preempt_count() will return 1.
If after the preemption is enabled if the CPU is offlined, there are hotplug callbacks to handle.
Thanks, Srinivas
thanks, Chenyu
Thanks, Pavel
+++ b/drivers/thermal/intel_powerclamp.c @@ -519,8 +519,10 @@ static int start_power_clamp(void) /* prefer BSP */ control_cpu = 0; - if (!cpu_online(control_cpu)) - control_cpu = smp_processor_id(); + if (!cpu_online(control_cpu)) { + control_cpu = get_cpu(); + put_cpu(); + } clamping = true; schedule_delayed_work(&poll_pkg_cstate_work, 0); -- 2.35.1
-- People of Russia, stop Putin before his war on Ukraine escalates.
On Tue, Oct 11, 2022 at 3:23 PM Chen Yu yu.c.chen@intel.com wrote:
Hi Pavel, On 2022-10-11 at 13:36:46 +0200, Pavel Machek wrote:
Hi!
From: Srinivas Pandruvada srinivas.pandruvada@linux.intel.com
[ Upstream commit 68b99e94a4a2db6ba9b31fe0485e057b9354a640 ]
When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace:
<TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ...
Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
This has exactly the same problem as smp_processor_id(), you just worked around the warning. If it is okay that control_cpu contains stale value, could we have a comment explaining why?
May I know why does control_cpu have stale value? The control_cpu is a random picked online CPU which will be used later to collect statistics. As long as the control_cpu is online, it is valid IMO.
So this is confusing, because the code makes the impression that getting the number of the CPU running the code matters in some way, which isn't the case.
Something like cpumask_first(cpu_online_mask) should work as well if I'm not mistaken and it would be less confusing to use this instead IMO.
On Wed, 2022-10-12 at 18:58 +0200, Rafael J. Wysocki wrote:
On Tue, Oct 11, 2022 at 3:23 PM Chen Yu yu.c.chen@intel.com wrote:
Hi Pavel, On 2022-10-11 at 13:36:46 +0200, Pavel Machek wrote:
Hi!
From: Srinivas Pandruvada srinivas.pandruvada@linux.intel.com
[ Upstream commit 68b99e94a4a2db6ba9b31fe0485e057b9354a640 ]
When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace:
<TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ...
Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
This has exactly the same problem as smp_processor_id(), you just worked around the warning. If it is okay that control_cpu contains stale value, could we have a comment explaining why?
May I know why does control_cpu have stale value? The control_cpu is a random picked online CPU which will be used later to collect statistics. As long as the control_cpu is online, it is valid IMO.
So this is confusing, because the code makes the impression that getting the number of the CPU running the code matters in some way, which isn't the case.
Something like cpumask_first(cpu_online_mask) should work as well if I'm not mistaken and it would be less confusing to use this instead IMO.
That should work as we are under hotplug lock anyway here.
Thanks, Srinivas
On Thu, Oct 13, 2022 at 5:06 AM srinivas pandruvada srinivas.pandruvada@linux.intel.com wrote:
On Wed, 2022-10-12 at 18:58 +0200, Rafael J. Wysocki wrote:
On Tue, Oct 11, 2022 at 3:23 PM Chen Yu yu.c.chen@intel.com wrote:
Hi Pavel, On 2022-10-11 at 13:36:46 +0200, Pavel Machek wrote:
Hi!
From: Srinivas Pandruvada srinivas.pandruvada@linux.intel.com
[ Upstream commit 68b99e94a4a2db6ba9b31fe0485e057b9354a640 ]
When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace:
<TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ...
Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
This has exactly the same problem as smp_processor_id(), you just worked around the warning. If it is okay that control_cpu contains stale value, could we have a comment explaining why?
May I know why does control_cpu have stale value? The control_cpu is a random picked online CPU which will be used later to collect statistics. As long as the control_cpu is online, it is valid IMO.
So this is confusing, because the code makes the impression that getting the number of the CPU running the code matters in some way, which isn't the case.
Something like cpumask_first(cpu_online_mask) should work as well if I'm not mistaken and it would be less confusing to use this instead IMO.
That should work as we are under hotplug lock anyway here.
Well, that's my point.
I guess I'll send a patch with this change.
linux-stable-mirror@lists.linaro.org
-
Chen Yu -
Pavel Machek -
Rafael J. Wysocki -
Sasha Levin -
srinivas pandruvada