kernel/linux.git/drivers/powercap/powercap_sys.c, branch v6.12.80

powercap: fix sscanf() error return value handling

2026-01-17T15:31:28+00:00

[ Upstream commit efc4c35b741af973de90f6826bf35d3b3ac36bf1 ] Fix inconsistent error handling for sscanf() return value check. Implicit boolean conversion is used instead of explicit return value checks. The code checks if (!sscanf(...)) which is incorrect because: 1. sscanf returns the number of successfully parsed items 2. On success, it returns 1 (one item passed) 3. On failure, it returns 0 or EOF 4. The check 'if (!sscanf(...))' is wrong because it treats success (1) as failure All occurrences of sscanf() now uses explicit return value check. With this behavior it returns '-EINVAL' when parsing fails (returns 0 or EOF), and continues when parsing succeeds (returns 1). Signed-off-by: Sumeet Pawnikar [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20251207151549.202452-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

powercap: fix race condition in register_control_type()

2026-01-17T15:31:27+00:00

[ Upstream commit 7bda1910c4bccd4b8d4726620bb3d6bbfb62286e ] The device becomes visible to userspace via device_register() even before it fully initialized by idr_init(). If userspace or another thread tries to register a zone immediately after device_register(), the control_type_valid() will fail because the control_type is not yet in the list. The IDR is not yet initialized, so this race condition causes zone registration failure. Move idr_init() and list addition before device_register() fix the race condition. Signed-off-by: Sumeet Pawnikar [ rjw: Subject adjustment, empty line added ] Link: https://patch.msgid.link/20251205190216.5032-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

powercap: call put_device() on an error path in powercap_register_control_type()

2025-03-22T19:54:14+00:00

[ Upstream commit 93c66fbc280747ea700bd6199633d661e3c819b3 ] powercap_register_control_type() calls device_register(), but does not release the refcount of the device when it fails. Call put_device() before returning an error to balance the refcount. Since the kfree(control_type) will be done by powercap_release(), remove the lines in powercap_register_control_type() before returning the error. This bug was found by an experimental verifier that I am developing. Signed-off-by: Joe Hattori Link: https://patch.msgid.link/20250110010554.1583411-1-joe@pf.is.s.u-tokyo.ac.jp [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

powercap: remove MODULE_LICENSE in non-modules

2023-02-28T20:32:05+00:00

Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by: Nick Alcock Suggested-by: Luis Chamberlain Signed-off-by: Rafael J. Wysocki

powercap: fix possible name leak in powercap_register_zone()

2023-01-20T13:57:23+00:00

In the error path after calling dev_set_name(), the device name is leaked. To fix this, calling dev_set_name() before device_register(), and call put_device() if it returns error. All the resources is released in powercap_release(), so it can return from powercap_register_zone() directly. Fixes: 75d2364ea0ca ("PowerCap: Add class driver") Signed-off-by: Yang Yingliang Signed-off-by: Rafael J. Wysocki

powercap: Use kstrtobool() instead of strtobool()

2022-11-03T18:38:16+00:00

strtobool() is the same as kstrtobool(). However, the latter is more used within the kernel. In order to remove strtobool() and slightly simplify kstrtox.h, switch to the other function name. While at it, include the corresponding header file () Signed-off-by: Christophe JAILLET Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-sleep', 'pm-acpi', 'pm-domains' and 'powercap'

2020-12-15T14:26:14+00:00

* pm-sleep: PM: sleep: Add dev_wakeup_path() helper PM / suspend: fix kernel-doc markup PM: sleep: Print driver flags for all devices during suspend/resume * pm-acpi: PM: ACPI: Refresh wakeup device power configuration every time PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup() PM: ACPI: reboot: Use S5 for reboot * pm-domains: PM: domains: create debugfs nodes when adding power domains PM: domains: replace -ENOTSUPP with -EOPNOTSUPP * powercap: powercap: Adjust printing the constraint name with new line powercap: RAPL: Add AMD Fam19h RAPL support powercap: Add AMD Fam17h RAPL support powercap/intel_rapl_msr: Convert rapl_msr_priv into pointer x86/msr-index: sort AMD RAPL MSRs by address

powercap: Adjust printing the constraint name with new line

2020-11-23T17:27:58+00:00

The constrain name has limit of size 30, which sometimes might be hit. When this happens the new line might get lost. Prevent this and set the max limit for name string length equal 29. This would result is proper string clamping (when needed) and storing '\n' at index 29 and '\0' at 30, so similarly as desired originally. Signed-off-by: Lukasz Luba Signed-off-by: Rafael J. Wysocki

powercap: restrict energy meter to root access

2020-11-10T16:40:57+00:00

Remove non-privileged user access to power data contained in /sys/class/powercap/intel-rapl*/*/energy_uj Non-privileged users currently have read access to power data and can use this data to form a security attack. Some privileged drivers/applications need read access to this data, but don't expose it to non-privileged users. For example, thermald uses this data to ensure that power management works correctly. Thus removing non-privileged access is preferred over completely disabling this power reporting capability with CONFIG_INTEL_RAPL=n. Fixes: 95677a9a3847 ("PowerCap: Fix mode for energy counter") Signed-off-by: Len Brown Cc: stable@vger.kernel.org

powercap: Invoke powercap_init() and rapl_init() earlier

2019-07-22T09:23:00+00:00

The MMIO RAPL interface driver depends on both powercap subsystem and the intel_rapl_common code. But when all of them are built-in, the MMIO RAPL interface driver can be loaded before the other two and this breaks the system during boot. Fix this by adjusting the init order of the powercap subsystem and the intel_rapl_common code, so that it can be initialized first. Fixes: 555c45fe0d04 ("int340X/processor_thermal_device: add support for MMIO RAPL") Reported-by: Kenneth R. Crudup Tested-by: Kenneth R. Crudup Signed-off-by: Zhang Rui [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki