[RFC][PATCH v3 0/8] ACPI: CPPC: Resource Priority Register support and sysfs interface

This series implements support for the CPPC v4 Resource Priority Register
mechanism defined in ACPI 6.6, Section 8.4.6.1.2.7, and exposes it to
userspace via sysfs.

Resource Priority allows OSPM to control the relative priority among
processors for shared resources.  The controlled resource types include
processor boost, throttle, L2 cache, L3 cache, and memory bandwidth.
Each Resource Priority group consists of:

  - CONTROLLED_RESOURCES: which resource types the group affects
  - ENABLE_VALUE / ENABLE_REGISTER: enable/disable the group
  - PRIORITY_COUNT / PRIORITY_REGISTER: read/write the priority level

The patch series is organized in three parts:

  - patches 1-4 extend the CPPC data structures and _CPC parser to handle
    Package-type entries and parse Resource Priority sub-packages into
    structured descriptors.

  - patches 5-7 refactor existing register I/O helpers to support direct
    register access and add accessor functions for Resource Priority
    attributes (enable, priority count, priority value).

  - patch 8 creates a "resource_priority" sysfs hierarchy under each
    cpufreq policy to expose the Resource Priority attributes to userspace.

Changelog:

v3:
 - Patch 2: Add the (i - 2) == RESOURCE_PRIORITY condition back to ensure
   the new code behaves the same as the original.
 - Patch 4: Assign -ENODATA to ret when an unexpected ACPI_TYPE_PACKAGE
   appears.
 - Patch 5: Initialize the `optional` field of the remaining cpc_regs to
   true so that they are treated as unsupported.
 - Patch 8: Call cppc_cpufreq_cpu_fie_exit() and set perf to lowest_perf
   when cppc_create_res_prio_sysfs() fails. Call kobject_put() and kfree()
   when kobject_init_and_add() fails in cppc_create_res_prio_sysfs().

v2:
 - Patch 1: Revert changes to the CPC_SUPPORTED() macro.
 - Link: https://lore.kernel.org/all/[email protected]/

v1:
 - Link: https://lore.kernel.org/all/[email protected]/

---

RFC: sysfs placement

The sysfs interface is currently placed under /sys/devices/system/cpu/cpufreq/
(i.e. the cpufreq policy directory). I am unsure whether this is the best
location and would appreciate reviewer feedback.

The concern is that Resource Priority covers resource types beyond CPU
frequency control:

  - PROCESSOR_BOOST, PROCESSOR_THROTTLE -- clearly CPU-frequency related
  - L2_CACHE, L3_CACHE -- cache partitioning, not frequency
  - MEMORY_BANDWIDTH -- memory QoS, not frequency

Placing the attributes under cpufreq makes sense for boost/throttle but
feels semantically wrong for cache and memory bandwidth resources.

I would appreciate feedback on whether cpufreq is the right home for
this interface, or whether a different location would be more appropriate.

Lifeng Zheng (8):
  ACPI: CPPC: Prepare cpc_register_resource for Package-type entries
  ACPI: CPPC: Refactor element parsing into parse_cpc_element()
  ACPI: CPPC: Refactor resource cleanup into free_reg_resource()
  ACPI: CPPC: Parse Resource Priority Register entries from _CPC package
  ACPI: CPPC: Store optional flag in cpc_register_resource
  ACPI: CPPC: Factor out cpc_read_reg() and cpc_write_reg()
  ACPI: CPPC: Add Resource Priority accessors
  cpufreq: cppc: Expose Resource Priority attributes via sysfs

 drivers/acpi/cppc_acpi.c       | 717 +++++++++++++++++++++++++++------
 drivers/cpufreq/cppc_cpufreq.c | 283 ++++++++++++-
 include/acpi/cppc_acpi.h       |  60 +++
 3 files changed, 930 insertions(+), 130 deletions(-)

-- 
2.33.0