summaryrefslogtreecommitdiff
path: root/drivers/acpi/cppc_acpi.c
AgeCommit message (Collapse)AuthorFilesLines
2024-12-14ACPI: CPPC: Fix _CPC register setting issueLifeng Zheng1-1/+0
[ Upstream commit 2388b266c9fcc7c9169ba85c7f9ebe325b7622d7 ] Since commit 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage"), _CPC registers cannot be changed from 1 to 0. It turns out that there is an extra OR after MASK_VAL_WRITE(), which has already ORed prev_val with the register mask. Remove the extra OR to fix the problem. Fixes: 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage") Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20241113103309.761031-1-zhenglifeng1@huawei.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-08ACPI: CPPC: Make rmw_lock a raw_spin_lockPierre Gondois1-4/+5
[ Upstream commit 1c10941e34c5fdc0357e46a25bd130d9cf40b925 ] The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. Fixes: 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage") Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Link: https://patch.msgid.link/20241028125657.1271512-1-pierre.gondois@arm.com [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17ACPI: CPPC: Fix MASK_VAL() usageClément Léger1-4/+39
[ Upstream commit 60949b7b805424f21326b450ca4f1806c06d982e ] MASK_VAL() was added as a way to handle bit_offset and bit_width for registers located in system memory address space. However, while suited for reading, it does not work for writing and result in corrupted registers when writing values with bit_offset > 0. Moreover, when a register is collocated with another one at the same address but with a different mask, the current code results in the other registers being overwritten with 0s. The write procedure for SYSTEM_MEMORY registers should actually read the value, mask it, update it and write it with the updated value. Moreover, since registers can be located in the same word, we must take care of locking the access before doing it. We should potentially use a global lock since we don't know in if register addresses aren't shared with another _CPC package but better not encourage vendors to do so. Assume that registers can use the same word inside a _CPC package and thus, use a per _CPC package lock. Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses") Signed-off-by: Clément Léger <cleger@rivosinc.com> Link: https://patch.msgid.link/20240826101648.95654-1-cleger@rivosinc.com [ rjw: Dropped redundant semicolon ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17ACPI: bus: Avoid using CPPC if not supported by firmwareRafael J. Wysocki1-0/+3
[ Upstream commit c42fa24b44751c62c86e98430ef915c0609a2ab8 ] If the platform firmware indicates that it does not support CPPC by clearing the OSC_SB_CPC_SUPPORT and OSC_SB_CPCV2_SUPPORT bits in the platform _OSC capabilities mask, avoid attempting to evaluate _CPC which may fail in that case. Because the OSC_SB_CPC_SUPPORT and OSC_SB_CPCV2_SUPPORT bits are only added to the supported platform capabilities mask on x86, when X86_FEATURE_HWP is supported, allow _CPC to be evaluated regardless in the other cases. Link: https://lore.kernel.org/linux-acpi/CAJZ5v0i=ecAksq0TV+iLVObm-=fUfdqPABzzkgm9K6KxO1ZCcg@mail.gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Stable-dep-of: 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17ACPI: CPPC: Fix access width used for PCC registersVanshidhar Konda1-12/+36
commit f489c948028b69cea235d9c0de1cc10eeb26a172 upstream commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses") modified cpc_read()/cpc_write() to use access_width to read CPC registers. However, for PCC registers the access width field in the ACPI register macro specifies the PCC subspace ID. For non-zero PCC subspace ID it is incorrectly treated as access width. This causes errors when reading from PCC registers in the CPPC driver. For PCC registers, base the size of read/write on the bit width field. The debug message in cpc_read()/cpc_write() is updated to print relevant information for the address space type used to read the register. Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses") Signed-off-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com> Tested-by: Jarred White <jarredwhite@linux.microsoft.com> Reviewed-by: Jarred White <jarredwhite@linux.microsoft.com> Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com> Cc: 5.15+ <stable@vger.kernel.org> # 5.15+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ eahariha: Backport to v5.15 by dropping SystemIO bits as commit a2c8f92bea5f is not present ] Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17ACPI: CPPC: Fix bit_offset shift in MASK_VAL() macroJarred White1-2/+2
commit 05d92ee782eeb7b939bdd0189e6efcab9195bf95 upstream Commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses") neglected to properly wrap the bit_offset shift when it comes to applying the mask. This may cause incorrect values to be read and may cause the cpufreq module not be loaded. [ 11.059751] cpu_capacity: CPU0 missing/invalid highest performance. [ 11.066005] cpu_capacity: partial information: fallback to 1024 for all CPUs Also, corrected the bitmask generation in GENMASK (extra bit being added). Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses") Signed-off-by: Jarred White <jarredwhite@linux.microsoft.com> Cc: 5.15+ <stable@vger.kernel.org> # 5.15+ Reviewed-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17Revert "Revert "ACPI: CPPC: Use access_width over bit_width for system ↵Easwar Hariharan1-3/+24
memory accesses"" This reverts commit b54c4632946ae42f2b39ed38abd909bbf78cbcc2 which was a revert of a backport of commit 2f4a4d63a193be6fd530d180bb13c3592052904c upstream to 5.15.y. Cc: Jarred White <jarredwhite@linux.microsoft.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Vanshidhar Konda <vanshikonda@os.amperecomputing.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-13Revert "ACPI: CPPC: Use access_width over bit_width for system memory accesses"Greg Kroah-Hartman1-24/+3
This reverts commit 4949affd5288b867cdf115f5b08d6166b2027f87 which is commit 2f4a4d63a193be6fd530d180bb13c3592052904c upstream. It breaks AmpereOne systems and should not have been added to the stable tree just yet. Link: https://lore.kernel.org/r/97d25ef7-dee9-4cc5-842a-273f565869b3@linux.microsoft.com Reported-by: Easwar Hariharan <eahariha@linux.microsoft.com> Cc: Jarred White <jarredwhite@linux.microsoft.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-10ACPI: CPPC: Use access_width over bit_width for system memory accessesJarred White1-3/+24
commit 2f4a4d63a193be6fd530d180bb13c3592052904c upstream. To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform. SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id. If access_width is not set, then fall back to using bit_width. Signed-off-by: Jarred White <jarredwhite@linux.microsoft.com> Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com> Cc: 5.15+ <stable@vger.kernel.org> # 5.15+ [ rjw: Subject and changelog edits, comment adjustments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ eahariha: Backport to v5.15 by dropping SystemIO bits as commit a2c8f92bea5f is not present ] Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-17ACPI: CPPC: Do not prevent CPPC from working in the futureRafael J. Wysocki1-30/+24
[ Upstream commit 4f4179fcf420873002035cf1941d844c9e0e7cb3 ] There is a problem with the current revision checks in is_cppc_supported() that they essentially prevent the CPPC support from working if a new _CPC package format revision being a proper superset of the v3 and only causing _CPC to return a package with more entries (while retaining the types and meaning of the entries defined by the v3) is introduced in the future and used by the platform firmware. In that case, as long as the number of entries in the _CPC return package is at least CPPC_V3_NUM_ENT, it should be perfectly fine to use the v3 support code and disregard the additional package entries added by the new package format revision. For this reason, drop is_cppc_supported() altogether, put the revision checks directly into acpi_cppc_processor_probe() so they are easier to follow and rework them to take the case mentioned above into account. Fixes: 4773e77cdc9b ("ACPI / CPPC: Add support for CPPC v3") Cc: 4.18+ <stable@vger.kernel.org> # 4.18+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-06-09ACPI: CPPC: Assume no transition latency if no PCCTPierre Gondois1-1/+16
[ Upstream commit 6380b7b2b29da9d9c5ab2d4a265901cd93ba3696 ] The transition_delay_us (struct cpufreq_policy) is currently defined as: Preferred average time interval between consecutive invocations of the driver to set the frequency for this policy. To be set by the scaling driver (0, which is the default, means no preference). The transition_latency represents the amount of time necessary for a CPU to change its frequency. A PCCT table advertises mutliple values: - pcc_nominal: Expected latency to process a command, in microseconds - pcc_mpar: The maximum number of periodic requests that the subspace channel can support, reported in commands per minute. 0 indicates no limitation. - pcc_mrtt: The minimum amount of time that OSPM must wait after the completion of a command before issuing the next command, in microseconds. cppc_get_transition_latency() allows to get the max of them. commit d4f3388afd48 ("cpufreq / CPPC: Set platform specific transition_delay_us") allows to select transition_delay_us based on the platform, and fallbacks to cppc_get_transition_latency() otherwise. If _CPC objects are not using PCC channels (no PPCT table), the transition_delay_us is set to CPUFREQ_ETERNAL, leading to really long periods between frequency updates (~4s). If the desired_reg, where performance requests are written, is in SystemMemory or SystemIo ACPI address space, there is no delay in requests. So return 0 instead of CPUFREQ_ETERNAL, leading to transition_delay_us being set to LATENCY_MULTIPLIER us (1000 us). This patch also adds two macros to check the address spaces. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ACPI: CPPC: Avoid out of bounds access when parsing _CPC dataRafael J. Wysocki1-0/+5
commit 40d8abf364bcab23bc715a9221a3c8623956257b upstream. If the NumEntries field in the _CPC return package is less than 2, do not attempt to access the "Revision" element of that package, because it may not be present then. Fixes: 337aadff8e45 ("ACPI: Introduce CPU performance controls using CPPC") BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/ Reported-by: kernel test robot <oliver.sang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27ACPI: CPPC: Check present CPUs for determining _CPC is validMario Limonciello1-1/+1
[ Upstream commit 2aeca6bd02776d7f56a49a32be0dd184f204d888 ] As this is a static check, it should be based upon what is currently present on the system. This makes probeing more deterministic. While local APIC flags field (lapic_flags) of cpu core in MADT table is 0, then the cpu core won't be enabled. In this case, _CPC won't be found in this core, and return back to _CPC invalid with walking through possible cpus (include disable cpus). This is not expected, so switch to check present CPUs instead. Reported-by: Jinzhou Su <Jinzhou.Su@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-01ACPI: CPPC: Add NULL pointer check to cppc_get_perf()Rafael J. Wysocki1-1/+8
commit 935dff305da2be7957a5ce8f07f45d6c4c1c6984 upstream. Check cpc_desc against NULL in cppc_get_perf(), so it doesn't crash down the road if cpc_desc is NULL. Fixes: 0654cf05d17b ("ACPI: CPPC: Introduce cppc_get_nominal_perf()") Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 5.15+ <stable@vger.kernel.org> # 5.15+ Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-07ACPI: CPPC: Introduce cppc_get_nominal_perf()Rafael J. Wysocki1-16/+31
On some systems the nominal_perf value retrieved via CPPC is just a constant and fetching it doesn't require accessing any registers, so if it is the only CPPC capability that's needed, it is wasteful to run cppc_get_perf_caps() in order to get just that value alone, especially when this is done for CPUs other than the one running the code. For this reason, introduce cppc_get_nominal_perf() allowing nominal_perf to be obtained individually, by generalizing the existing cppc_get_desired_perf() (and renaming it) so it can be used to retrieve any specific CPPC capability value. While at it, clean up the cppc_get_desired_perf() kerneldoc comment a bit. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-04-26Merge branch 'acpi-misc'Rafael J. Wysocki1-40/+41
* acpi-misc: ACPI: dock: fix some coding style issues ACPI: sysfs: fix some coding style issues ACPI: PM: add a missed blank line after declarations ACPI: custom_method: fix a coding style issue ACPI: CPPC: fix some coding style issues ACPI: button: fix some coding style issues ACPI: battery: fix some coding style issues ACPI: acpi_pad: add a missed blank line after declarations ACPI: LPSS: add a missed blank line after declarations ACPI: ipmi: remove useless return statement for void function ACPI: processor: fix some coding style issues ACPI: APD: fix a block comment align issue ACPI: AC: fix some coding style issues ACPI: fix various typos in comments
2021-04-08ACPI: CPPC: Replace cppc_attr with kobj_attributeNathan Chancellor1-11/+3
All of the CPPC sysfs show functions are called via indirect call in kobj_attr_show(), where they should be of type ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr, char *buf); because that is the type of the ->show() member in 'struct kobj_attribute' but they are actually of type ssize_t (*show)(struct kobject *kobj, struct attribute *attr, char *buf); because of the ->show() member in 'struct cppc_attr', resulting in a Control Flow Integrity violation [1]. $ cat /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf 3400 $ dmesg | grep "CFI failure" [ 175.970559] CFI failure (target: show_highest_perf+0x0/0x8): As far as I can tell, the only difference between 'struct cppc_attr' and 'struct kobj_attribute' aside from the type of the attr parameter is the type of the count parameter in the ->store() member (ssize_t vs. size_t), which does not actually matter because all of these nodes are read-only. Eliminate 'struct cppc_attr' in favor of 'struct kobj_attribute' to fix the violation. [1]: https://lore.kernel.org/r/20210401233216.2540591-1-samitolvanen@google.com/ Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered performance") Link: https://github.com/ClangBuiltLinux/linux/issues/1343 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-04-08ACPI: CPPC: fix some coding style issuesXiaofei Tan1-35/+36
Fix some coding style issues reported by checkpatch.pl, including the following types: WARNING: Missing a blank line after declarations WARNING: unnecessary whitespace before a quoted newline ERROR: spaces required around that '>=' ERROR: switch and case should be at the same indent Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-03-23ACPI: CPPC: Add emtpy stubs of functions for CONFIG_ACPI_CPPC_LIB unsetRafael J. Wysocki1-1/+0
For convenience, add empty stubs of library functions defined in cppc_acpi.c for the CONFIG_ACPI_CPPC_LIB unset case. Because one of them needs to return CPUFREQ_ETERNAL, include linux/cpufreq.h into the CPPC library header file and drop the direct inclusion of it from cppc_acpi.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com>
2021-03-19ACPI: fix various typos in commentsTom Saeger1-5/+5
Fix trivial ACPI driver comment typos. s/notifcations/notifications/ s/Ajust/Adjust/ s/preform/perform/ s/atrributes/attributes/ s/Souce/Source/ s/Evalutes/Evaluates/ s/Evalutes/Evaluates/ s/specifiy/specify/ s/promixity/proximity/ s/presuambly/presumably/ s/Evalute/Evaluate/ s/specificed/specified/ s/rountine/routine/ s/previosuly/previously/ Change comment referencing pcc_send_cmd to send_pcc_cmd. Signed-off-by: Tom Saeger <tom.saeger@oracle.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-22ACPI: CPPC: initialise vaddr pointers to NULLIonela Voinescu1-2/+2
Properly initialise vaddr pointers in cpc_read() and cpc_write() to NULL instead of 0. This fixes the following sparse warnings: drivers/acpi/cppc_acpi.c:937:31: warning: Using plain integer as NULL pointer drivers/acpi/cppc_acpi.c:982:31: warning: Using plain integer as NULL pointer Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-22ACPI: CPPC: add __iomem annotation to generic_comm_base pointerIonela Voinescu1-2/+2
ppc_comm_addr is a virtual address to the PCC space and it's annotated with __iomem. Therefore, generic_comm_base which gets assigned the value of pcc_comm_address should be annotated as well. This already happens in check_pcc_chan(), but not in send_pcc_cmd(), which results in the following sparse warnings: drivers/acpi/cppc_acpi.c:237:18: warning: cast removes address space '__iomem' of expression drivers/acpi/cppc_acpi.c:299:9: warning: incorrect type in argument 2 (different address spaces) drivers/acpi/cppc_acpi.c:299:9: expected void volatile [noderef] __iomem *addr drivers/acpi/cppc_acpi.c:299:9: got unsigned short * drivers/acpi/cppc_acpi.c:302:9: warning: incorrect type in argument 2 (different address spaces) drivers/acpi/cppc_acpi.c:302:9: expected void volatile [noderef] __iomem *addr drivers/acpi/cppc_acpi.c:302:9: got unsigned short * Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-22Merge branch 'pm-cpufreq'Rafael J. Wysocki1-81/+60
* pm-cpufreq: cpufreq: intel_pstate: Use most recent guaranteed performance values cpufreq: intel_pstate: Implement the ->adjust_perf() callback cpufreq: Add special-purpose fast-switching callback for drivers cpufreq: schedutil: Add util to struct sg_cpu cppc_cpufreq: replace per-cpu data array with a list cppc_cpufreq: expose information on frequency domains cppc_cpufreq: clarify support for coordination types cppc_cpufreq: use policy->cpu as driver of frequency setting ACPI: processor: fix NONE coordination for domain mapping failure ACPI: processor: Drop duplicate setting of shared_cpu_map
2020-12-15cppc_cpufreq: replace per-cpu data array with a listIonela Voinescu1-81/+60
The cppc_cpudata per-cpu storage was inefficient (1) additional to causing functional issues (2) when CPUs are hotplugged out, due to per-cpu data being improperly initialised. (1) The amount of information needed for CPPC performance control in its cpufreq driver depends on the domain (PSD) coordination type: ANY: One set of CPPC control and capability data (e.g desired performance, highest/lowest performance, etc) applies to all CPUs in the domain. ALL: Same as ANY. To be noted that this type is not currently supported. When supported, information about which CPUs belong to a domain is needed in order for frequency change requests to be sent to each of them. HW: It's necessary to store CPPC control and capability information for all the CPUs. HW will then coordinate the performance state based on their limitations and requests. NONE: Same as HW. No HW coordination is expected. Despite this, the previous initialisation code would indiscriminately allocate memory for all CPUs (all_cpu_data) and unnecessarily duplicate performance capabilities and the domain sharing mask and type for each possible CPU. (2) With the current per-cpu structure, when having ANY coordination, the cppc_cpudata cpu information is not initialised (will remain 0) for all CPUs in a policy, other than policy->cpu. When policy->cpu is hotplugged out, the driver will incorrectly use the uninitialised (0) value of the other CPUs when making frequency changes. Additionally, the previous values stored in the perf_ctrls.desired_perf will be lost when policy->cpu changes. Therefore replace the array of per cpu data with a list. The memory for each structure is allocated at policy init, where a single structure can be allocated per policy, not per cpu. In order to accommodate the struct list_head node in the cppc_cpudata structure, the now unused cpu and cur_policy variables are removed. For example, on a arm64 Juno platform with 6 CPUs: (0, 1, 2, 3) in PSD1, (4, 5) in PSD2 - ANY coordination, the memory allocation comparison shows: Before patch: - ANY coordination: total slack req alloc/free caller 0 0 0 0/1 _kernel_size_le_hi32+0x0xffff800008ff7810 0 0 0 0/6 _kernel_size_le_hi32+0x0xffff800008ff7808 128 80 48 1/0 _kernel_size_le_hi32+0x0xffff800008ffc070 768 0 768 6/0 _kernel_size_le_hi32+0x0xffff800008ffc0e4 After patch: - ANY coordination: total slack req alloc/free caller 256 0 256 2/0 _kernel_size_le_hi32+0x0xffff800008fed410 0 0 0 0/2 _kernel_size_le_hi32+0x0xffff800008fed274 Additional notes: - A pointer to the policy's cppc_cpudata is stored in policy->driver_data - Driver registration is skipped if _CPC entries are not present. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Tested-by: Mian Yousaf Kaukab <ykaukab@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-15ACPI: processor: fix NONE coordination for domain mapping failureIonela Voinescu1-1/+1
For errors parsing the _PSD domains, a separate domain is returned for each CPU in the failed _PSD domain with no coordination (as per previous comment). But contrary to the intention, the code was setting CPUFREQ_SHARED_TYPE_ALL as coordination type. Change shared_type to CPUFREQ_SHARED_TYPE_NONE in case of errors parsing the domain information. The function still returns the error and the caller is free to bail out the domain initialisation altogether in that case. Given that both functions return domains with a single CPU, this change does not affect the functionality, but clarifies the intention. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-11x86, sched: Calculate frequency invariance for AMD systemsNathan Fontenot1-0/+7
This is the first pass in creating the ability to calculate the frequency invariance on AMD systems. This approach uses the CPPC highest performance and nominal performance values that range from 0 - 255 instead of a high and base frquency. This is because we do not have the ability on AMD to get a highest frequency value. On AMD systems the highest performance and nominal performance vaues do correspond to the highest and base frequencies for the system so using them should produce an appropriate ratio but some tweaking is likely necessary. Due to CPPC being initialized later in boot than when the frequency invariant calculation is currently made, I had to create a callback from the CPPC init code to do the calculation after we have CPPC data. Special thanks to "kernel test robot <lkp@intel.com>" for reporting that compilation of drivers/acpi/cppc_acpi.c is conditional to CONFIG_ACPI_CPPC_LIB, not just CONFIG_ACPI. [ ggherdovich@suse.cz: made safe under CPU hotplug, edited changelog. ] Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lkml.kernel.org/r/20201112182614.10700-2-ggherdovich@suse.cz
2020-05-28ACPI: CPPC: Fix reference count leak in acpi_cppc_processor_probe()Qiushi Wu1-0/+1
kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit "b8eb718348b8" fixed a similar problem. Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered performance") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Cc: 4.10+ <stable@vger.kernel.org> # 4.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-04-27ACPI: CPPC: Make some symbols staticZou Wei1-2/+2
Fix the following sparse warnings: drivers/acpi/cppc_acpi.c:353:20: warning: symbol 'cppc_mbox_cl' was not declared. Should it be static? drivers/acpi/cppc_acpi.c:600:5: warning: symbol 'pcc_data_alloc' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-03-28ACPI: CPPC: clean up acpi_get_psd_map()Liguang Zhang1-26/+7
In acpi_get_psd_map() variable all_cpu_data[] can't be NULL and variable match_cpc_ptr has been checked before, no need check again at the end of the funchtion. Some additional optimizations can be made on top of that. Signed-off-by: Liguang Zhang <zhangliguang@linux.alibaba.com> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-18ACPI: CPPC: Set pcc_data[pcc_ss_id] to NULL in acpi_cppc_processor_exit()John Garry1-1/+1
When enabling KASAN and DEBUG_TEST_DRIVER_REMOVE, I find this KASAN warning: [ 20.872057] BUG: KASAN: use-after-free in pcc_data_alloc+0x40/0xb8 [ 20.878226] Read of size 4 at addr ffff00236cdeb684 by task swapper/0/1 [ 20.884826] [ 20.886309] CPU: 19 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00009-ge7f7df3db5bf-dirty #289 [ 20.894994] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019 [ 20.903505] Call trace: [ 20.905942] dump_backtrace+0x0/0x200 [ 20.909593] show_stack+0x14/0x20 [ 20.912899] dump_stack+0xd4/0x130 [ 20.916291] print_address_description.isra.9+0x6c/0x3b8 [ 20.921592] __kasan_report+0x12c/0x23c [ 20.925417] kasan_report+0xc/0x18 [ 20.928808] __asan_load4+0x94/0xb8 [ 20.932286] pcc_data_alloc+0x40/0xb8 [ 20.935938] acpi_cppc_processor_probe+0x4e8/0xb08 [ 20.940717] __acpi_processor_start+0x48/0xb0 [ 20.945062] acpi_processor_start+0x40/0x60 [ 20.949235] really_probe+0x118/0x548 [ 20.952887] driver_probe_device+0x7c/0x148 [ 20.957059] device_driver_attach+0x94/0xa0 [ 20.961231] __driver_attach+0xa4/0x110 [ 20.965055] bus_for_each_dev+0xe8/0x158 [ 20.968966] driver_attach+0x30/0x40 [ 20.972531] bus_add_driver+0x234/0x2f0 [ 20.976356] driver_register+0xbc/0x1d0 [ 20.980182] acpi_processor_driver_init+0x40/0xe4 [ 20.984875] do_one_initcall+0xb4/0x254 [ 20.988700] kernel_init_freeable+0x24c/0x2f8 [ 20.993047] kernel_init+0x10/0x118 [ 20.996524] ret_from_fork+0x10/0x18 [ 21.000087] [ 21.001567] Allocated by task 1: [ 21.004785] save_stack+0x28/0xc8 [ 21.008089] __kasan_kmalloc.isra.9+0xbc/0xd8 [ 21.012435] kasan_kmalloc+0xc/0x18 [ 21.015913] pcc_data_alloc+0x94/0xb8 [ 21.019564] acpi_cppc_processor_probe+0x4e8/0xb08 [ 21.024343] __acpi_processor_start+0x48/0xb0 [ 21.028689] acpi_processor_start+0x40/0x60 [ 21.032860] really_probe+0x118/0x548 [ 21.036512] driver_probe_device+0x7c/0x148 [ 21.040684] device_driver_attach+0x94/0xa0 [ 21.044855] __driver_attach+0xa4/0x110 [ 21.048680] bus_for_each_dev+0xe8/0x158 [ 21.052591] driver_attach+0x30/0x40 [ 21.056155] bus_add_driver+0x234/0x2f0 [ 21.059980] driver_register+0xbc/0x1d0 [ 21.063805] acpi_processor_driver_init+0x40/0xe4 [ 21.068497] do_one_initcall+0xb4/0x254 [ 21.072322] kernel_init_freeable+0x24c/0x2f8 [ 21.076667] kernel_init+0x10/0x118 [ 21.080144] ret_from_fork+0x10/0x18 [ 21.083707] [ 21.085186] Freed by task 1: [ 21.088056] save_stack+0x28/0xc8 [ 21.091360] __kasan_slab_free+0x118/0x180 [ 21.095445] kasan_slab_free+0x10/0x18 [ 21.099183] kfree+0x80/0x268 [ 21.102139] acpi_cppc_processor_exit+0x1a8/0x1b8 [ 21.106832] acpi_processor_stop+0x70/0x80 [ 21.110917] really_probe+0x174/0x548 [ 21.114568] driver_probe_device+0x7c/0x148 [ 21.118740] device_driver_attach+0x94/0xa0 [ 21.122912] __driver_attach+0xa4/0x110 [ 21.126736] bus_for_each_dev+0xe8/0x158 [ 21.130648] driver_attach+0x30/0x40 [ 21.134212] bus_add_driver+0x234/0x2f0 [ 21.0x10/0x18 [ 21.161764] [ 21.163244] The buggy address belongs to the object at ffff00236cdeb600 [ 21.163244] which belongs to the cache kmalloc-256 of size 256 [ 21.175750] The buggy address is located 132 bytes inside of [ 21.175750] 256-byte region [ffff00236cdeb600, ffff00236cdeb700) [ 21.187473] The buggy address belongs to the page: [ 21.192254] page:fffffe008d937a00 refcount:1 mapcount:0 mapping:ffff002370c0fa00 index:0x0 compound_mapcount: 0 [ 21.202331] flags: 0x1ffff00000010200(slab|head) [ 21.206940] raw: 1ffff00000010200 dead000000000100 dead000000000122 ffff002370c0fa00 [ 21.214671] raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000 [ 21.222400] page dumped because: kasan: bad access detected [ 21.227959] [ 21.229438] Memory state around the buggy address: [ 21.234218] ffff00236cdeb580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 21.241427] ffff00236cdeb600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 21.248637] >ffff00236cdeb680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 21.255845] ^ [ 21.259062] ffff00236cdeb700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 21.266272] ffff00236cdeb780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 21.273480] ================================================================== It seems that global pcc_data[pcc_ss_id] can be freed in acpi_cppc_processor_exit(), but we may later reference this value, so NULLify it when freed. Also remove the useless setting of data "pcc_channel_acquired", which we're about to free. Fixes: 85b1407bf6d2 ("ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs") Signed-off-by: John Garry <john.garry@huawei.com> Cc: 4.15+ <stable@vger.kernel.org> # 4.15+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-08-28ACPI / CPPC: do not require the _PSD methodAl Stone1-2/+4
According to the ACPI 6.3 specification, the _PSD method is optional when using CPPC. The underlying assumption is that each CPU can change frequency independently from all other CPUs; _PSD is provided to tell the OS that some processors can NOT do that. However, the acpi_get_psd() function returns ENODEV if there is no _PSD method present, or an ACPI error status if an error occurs when evaluating _PSD, if present. This makes _PSD mandatory when using CPPC, in violation of the specification, and only on Linux. This has forced some firmware writers to provide a dummy _PSD, even though it is irrelevant, but only because Linux requires it; other OSPMs follow the spec. We really do not want to have OS specific ACPI tables, though. So, correct acpi_get_psd() so that it does not return an error if there is no _PSD method present, but does return a failure when the method can not be executed properly. This allows _PSD to be optional as it should be. Signed-off-by: Al Stone <ahs3@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441Thomas Gleixner1-5/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation version 2 of the license extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 315 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-06Merge branches 'acpi-scan', 'acpi-tables', 'acpi-misc' and 'acpi-pm'Rafael J. Wysocki1-17/+17
* acpi-scan: ACPI / scan: Add labels for PNP button devices ACPI / scan: Simplify acpi_bus_extract_wakeup_device_power_package() * acpi-tables: ACPI / tables: Clean up whitespace * acpi-misc: ACPI / DPTF: Use dev_get_drvdata() ACPI: event: replace strcpy() by strscpy() ACPI: Fix comment typos * acpi-pm: ACPI: PM: Print debug messages when enabling GPEs for wakeup
2019-03-27ACPI: Fix comment typosBjorn Helgaas1-17/+17
Fix some misspellings in comments. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-03-26ACPI / CPPC: Fix guaranteed performance handlingSrinivas Pandruvada1-2/+7
As per the ACPI specification, "Guaranteed Performance Register" is a "Buffer" field and it cannot be "Integer", so treat the "Integer" type for "Guaranteed Performance Register" field as invalid and ignore its value in that case. Also save one cpc_read() call when "Guaranteed Performance Register" is not present, which means a register defined as: "Register(SystemMemory, 0, 0, 0, 0)". Fixes: 29523f095397 ("ACPI / CPPC: Add support for guaranteed performance") Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: 4.20+ <stable@vger.kernel.org> # 4.20+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-02-18ACPI / CPPC: Add a helper to get desired performanceXiongfeng Wang1-0/+42
This patch add a helper to get the value of desired performance register. Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> [ rjw: More white space ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-10-16ACPI / CPPC: Add support for guaranteed performanceSrinivas Pandruvada1-2/+6
The Continuous Performance Control package may contain an optional guaranteed performance field. Add support to read guaranteed performance from _CPC. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-10ACPI / CPPC: Fix invalid PCC channel status errorsPrakash, Prashanth1-29/+19
Replace the faulty PCC status register polling code with a iopoll.h macro to fix incorrect reporting of PCC check errors ("PCC check channel failed"). There were potential codepaths where we could incorrectly return PCC channel status as busy even without checking the PCC status register once or not checking the status register before breaking out of the polling loop. For example, if the thread polling PCC status register was preempted and scheduled back after we have crossed the deadline then we can report that the channel is busy even without checking the status register. Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-24ACPI / CPPC: Check for valid PCC subspace only if PCC is usedPrashanth Prakash1-9/+21
Changes the behavior where we return error if there are no valid PCC subspace for a given performance domain. The ACPI spec does not mandate the use PCC, so it is possible to have platforms where a PCC subspace may not be present, so we need to check for a valid PCC subspace ID only if the register is a PCC register. Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-24ACPI / CPPC: Add support for CPPC v3Prashanth Prakash1-16/+65
CPPC V3 introduces two new entries to make it easier to convert between abstract processor performance and frequency. The two new entries are lowest frequency and nominal frequency. These are the frequencies corresponding to lowest and nominal abstract performance. Add support to read the new entries and populate them as part of the CPPC performance capabilities which can be used by cpufreq drivers Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-23ACPI / CPPC: Update all pr_(debug/err) messages to log the susbspace idGeorge Cherian1-11/+16
CPPC dirver is aware of multiple PCC subspace IDs. Enhance the debug and error messages in the driver to print the subspace id. In case of error it will be helpful to find which particular subspace is failing. Signed-off-by: George Cherian <george.cherian@cavium.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-07ACPI / CPPC: Use 64-bit arithmetic instead of 32-bitGustavo A. R. Silva1-1/+1
Add suffix ULL to constant 500 in order to give the compiler complete information about the proper arithmetic to use. Notice that this constant is used in a context that expects an expression of type u64 (64 bits, unsigned). The expression NUM_RETRIES * cppc_ss->latency at line 578, which at preprocessing time translates to 500 * cppc_ss->latency is currently being evaluated using 32-bit arithmetic. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-18ACPI: CPPC: remove initial assignment of pcc_ss_dataColin Ian King1-1/+1
The initialization of pcc_ss_data from pcc_data[pcc_ss_id] before pcc_ss_id is being range checked could lead to an out-of-bounds array read. This very same initialization is also being performed after the range check on pcc_ss_id, so we can just remove this problematic and also redundant assignment to fix the issue. Detected by cppcheck: warning: Value stored to 'pcc_ss_data' during its initialization is never read Fixes: 85b1407bf6d2 (ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-06ACPI / CPPC: Fix KASAN global out of bounds warningGeorge Cherian1-8/+15
Default value of pcc_subspace_idx is -1. Make sure to check pcc_subspace_idx before using the same as array index. This will avoid following KASAN warnings too. [ 15.113449] ================================================================== [ 15.116983] BUG: KASAN: global-out-of-bounds in cppc_get_perf_caps+0xf3/0x3b0 [ 15.116983] Read of size 8 at addr ffffffffb9a5c0d8 by task swapper/0/1 [ 15.116983] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2+ #2 [ 15.116983] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.2.8 01/26/2016 [ 15.116983] Call Trace: [ 15.116983] dump_stack+0x7c/0xbb [ 15.116983] print_address_description+0x1df/0x290 [ 15.116983] kasan_report+0x28a/0x370 [ 15.116983] ? cppc_get_perf_caps+0xf3/0x3b0 [ 15.116983] cppc_get_perf_caps+0xf3/0x3b0 [ 15.116983] ? cpc_read+0x210/0x210 [ 15.116983] ? __rdmsr_on_cpu+0x90/0x90 [ 15.116983] ? rdmsrl_on_cpu+0xa9/0xe0 [ 15.116983] ? rdmsr_on_cpu+0x100/0x100 [ 15.116983] ? wrmsrl_on_cpu+0x9c/0xd0 [ 15.116983] ? wrmsrl_on_cpu+0x9c/0xd0 [ 15.116983] ? wrmsr_on_cpu+0xe0/0xe0 [ 15.116983] __intel_pstate_cpu_init.part.16+0x3a2/0x530 [ 15.116983] ? intel_pstate_init_cpu+0x197/0x390 [ 15.116983] ? show_no_turbo+0xe0/0xe0 [ 15.116983] ? __lockdep_init_map+0xa0/0x290 [ 15.116983] intel_pstate_cpu_init+0x30/0x60 [ 15.116983] cpufreq_online+0x155/0xac0 [ 15.116983] cpufreq_add_dev+0x9b/0xb0 [ 15.116983] subsys_interface_register+0x1ae/0x290 [ 15.116983] ? bus_unregister_notifier+0x40/0x40 [ 15.116983] ? mark_held_locks+0x83/0xb0 [ 15.116983] ? _raw_write_unlock_irqrestore+0x32/0x60 [ 15.116983] ? intel_pstate_setup+0xc/0x104 [ 15.116983] ? intel_pstate_setup+0xc/0x104 [ 15.116983] ? cpufreq_register_driver+0x1ce/0x2b0 [ 15.116983] cpufreq_register_driver+0x1ce/0x2b0 [ 15.116983] ? intel_pstate_setup+0x104/0x104 [ 15.116983] intel_pstate_register_driver+0x3a/0xa0 [ 15.116983] intel_pstate_init+0x3c4/0x434 [ 15.116983] ? intel_pstate_setup+0x104/0x104 [ 15.116983] ? intel_pstate_setup+0x104/0x104 [ 15.116983] do_one_initcall+0x9c/0x206 [ 15.116983] ? parameq+0xa0/0xa0 [ 15.116983] ? initcall_blacklisted+0x150/0x150 [ 15.116983] ? lock_downgrade+0x2c0/0x2c0 [ 15.116983] kernel_init_freeable+0x327/0x3f0 [ 15.116983] ? start_kernel+0x612/0x612 [ 15.116983] ? _raw_spin_unlock_irq+0x29/0x40 [ 15.116983] ? finish_task_switch+0xdd/0x320 [ 15.116983] ? finish_task_switch+0x8e/0x320 [ 15.116983] ? rest_init+0xd0/0xd0 [ 15.116983] kernel_init+0xf/0x11a [ 15.116983] ? rest_init+0xd0/0xd0 [ 15.116983] ret_from_fork+0x24/0x30 [ 15.116983] The buggy address belongs to the variable: [ 15.116983] __key.36299+0x38/0x40 [ 15.116983] Memory state around the buggy address: [ 15.116983] ffffffffb9a5bf80: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa [ 15.116983] ffffffffb9a5c000: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa [ 15.116983] >ffffffffb9a5c080: fa fa fa fa 00 fa fa fa fa fa fa fa 00 00 00 00 [ 15.116983] ^ [ 15.116983] ffffffffb9a5c100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 15.116983] ffffffffb9a5c180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 15.116983] ================================================================== Fixes: 85b1407bf6d2 (ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs) Reported-by: Changbin Du <changbin.du@intel.com> Signed-off-by: George Cherian <george.cherian@cavium.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-09ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDsGeorge Cherian1-89/+151
Based on ACPI 6.2 Section 8.4.7.1.9 If the PCC register space is used, all PCC registers, for all processors in the same performance domain (as defined by _PSD), must be defined to be in the same subspace. Based on Section 14.1 of ACPI specification, it is possible to have a maximum of 256 PCC subspace IDs. Add support of multiple PCC subspace ID instead of using a single global pcc_data structure. While at that, fix the time_delta check in send_pcc_cmd() so that last_mpar_reset and mpar_count are initialized properly. Signed-off-by: George Cherian <george.cherian@cavium.com> Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-05-09scripts/spelling.txt: add regsiter -> register spelling mistakeStephen Boyd1-1/+1
This typo is quite common. Fix it and add it to the spelling file so that checkpatch catches it earlier. Link: http://lkml.kernel.org/r/20170317011131.6881-2-sboyd@codeaurora.org Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-04-19ACPI / CPPC: add sysfs entries for CPPC perf capabilitiesPrakash, Prashanth1-28/+33
Computed delivered performance using CPPC feedback counters are in the CPPC abstract scale, whereas cppc_cpufreq driver operates in KHz scale. Exposing the CPPC performance capabilities (highest,lowest, nominal, lowest non-linear) will allow userspace to figure out the conversion factor from CPPC abstract scale to KHz. Also rename ctr_wrap_time to wraparound_time so that show_cppc_data() macro will work with it. Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-19ACPI / CPPC: Read lowest nonlinear perf in cppc_get_perf_caps()Prakash, Prashanth1-8/+11
Read lowest non linear perf in cppc_get_perf_caps so that it can be exposed via sysfs to the usespace. Lowest non linear perf is the lowest performance level at which nonlinear power savings are achieved. Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-13ACPI / CPPC: Fix per-CPU pointer management in acpi_cppc_processor_probe()Rafael J. Wysocki1-4/+6
Fix a possible use-after-free scenario in acpi_cppc_processor_probe() that can happen if the function returns without cleaning up the per-CPU pointer set by it previously. Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-13ACPI / CPPC: Fix crash in acpi_cppc_processor_exit()Sebastian Andrzej Siewior1-0/+2
First I had crashed what I bisected down to de966cf4a4fa (sched/x86: Change CONFIG_SCHED_ITMT to CONFIG_SCHED_MC_PRIO) because it made SCHED_ITMT the default. Then I run another bisect round and got here with the same backtrace: |BUG: unable to handle kernel NULL pointer dereference at (null) |IP: [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 |PGD 0 [ 0.577616] |Oops: 0000 [#1] SMP |Modules linked in: |CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc6-00146-g17669006adf6 #51 |task: ffff88003f878000 task.stack: ffffc90000008000 |RIP: 0010:[<ffffffff812aab6e>] [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 |RSP: 0000:ffffc9000000bd48 EFLAGS: 00010296 |RAX: 00000000000137e0 RBX: 0000000000000000 RCX: 0000000000000001 |RDX: ffff88003fc00000 RSI: 0000000000000000 RDI: ffff88003fbca130 |RBP: ffffc9000000bd60 R08: 0000000000000514 R09: 0000000000000000 |R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002 |R13: 0000000000000020 R14: ffffffff8167cb00 R15: 0000000000000000 |FS: 0000000000000000(0000) GS:ffff88003fcc0000(0000) knlGS:0000000000000000 |CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 |CR2: 0000000000000000 CR3: 0000000001618000 CR4: 00000000000406e0 |Stack: | ffff88003f939848 ffff88003fbca130 0000000000000001 ffffc9000000bd80 | ffffffff812a4ccb ffff88003fc0cee8 0000000000000000 ffffc9000000bdb8 | ffffffff812dc20d ffff88003fc0cee8 ffffffff8167cb00 ffff88003fc0cf48 |Call Trace: | [<ffffffff812a4ccb>] acpi_processor_stop+0xb2/0xc5 | [<ffffffff812dc20d>] driver_probe_device+0x14d/0x2f0 | [<ffffffff812dc41e>] __driver_attach+0x6e/0x90 | [<ffffffff812da234>] bus_for_each_dev+0x54/0x90 | [<ffffffff812dbbf9>] driver_attach+0x19/0x20 | [<ffffffff812db6a6>] bus_add_driver+0xe6/0x200 | [<ffffffff812dcb23>] driver_register+0x83/0xc0 | [<ffffffff816f050a>] acpi_processor_driver_init+0x20/0x94 | [<ffffffff81000487>] do_one_initcall+0x97/0x180 | [<ffffffff816ccf5c>] kernel_init_freeable+0x112/0x1a6 | [<ffffffff813a0fc9>] kernel_init+0x9/0xf0 | [<ffffffff813acf35>] ret_from_fork+0x25/0x30 |Code: 02 00 00 00 48 8b 14 d5 e0 c3 55 81 48 8b 1c 02 4c 8d 6b 20 eb 15 49 8b 7d 00 48 85 ff 74 05 e8 39 8c d9 ff 41 ff c4 49 83 c5 20 <44> 3b 23 72 e6 48 8d bb a0 02 00 00 e8 b1 6f f9 ff 48 89 df e8 |RIP [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 | RSP <ffffc9000000bd48> |CR2: 0000000000000000 |---[ end trace 917a625107b09711 ]--- Fix it. Fixes: 17669006adf6 (cpufreq/intel_pstate: Use CPPC to get max performance) Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-26 11:14:44 +0300