platform/surface: add SP11 platform profile and low-power cap

[ooaklee]

Summary

• keep the platform-profile class available to device-tree providers when ACPI is disabled at runtime
• instantiate the existing Surface profile and fan-speed devices for Surface Pro 11
• apply an SP11-only 2.515 GHz CPU-frequency ceiling while the low-power profile is selected

Dependency and status

This PR targets jg/ubuntu-qcom-x1e-7.2.y directly and is the final contained platform-profile topic in the ordered SP11 extraction:

• battery-provider prerequisite: platform/surface: omit duplicate SP11 SAM power supplies #90

The branch is based directly on the current release branch, including the volume-key work merged through #82. It does not merge the #90 prerequisite head, the broad -sp11 staging branch, or #81's staging-fix branch.

The battery topic and this topic both edit ssam_node_group_sp11. This direct-base branch keeps the platform-profile diff independently reviewable, but it must be rebased/re-lifted after #90 merges. That re-lift must preserve both battery-provider omissions from #90 as well as the profile and fan additions here before this PR can leave draft status.

This PR is a draft because it touches shared platform-profile framework code and requires the SP11 and cross-device checks below before it is ready.

Containment

• with CONFIG_ACPI=y, the platform-profile class remains available to device-tree providers when ACPI is disabled at runtime, including an acpi=off boot; the legacy ACPI attribute group is still created only when ACPI has initialized successfully and its kobject is available
• CONFIG_ACPI=n is not a supported build case for this change: both ACPI_PLATFORM_PROFILE and SURFACE_PLATFORM_PROFILE are selected from ACPI-dependent Kconfig paths, so relocating those subsystems is outside this topic
• legacy ACPI notifications and teardown are guarded by the recorded attribute-group state
• profile and fan nodes are added only to the Denali Surface registry group
• CPU-frequency QoS is allocated only when a device supplies the low-power-max-frequency-khz property
• that property and the default low-power selection are present only on the SP11 software node
• existing Surface devices without the property retain the legacy TMP-then-fan write order, including same-profile writes; they do not enter the new readback transaction and allocate no QoS request
• existing online CPU policies are replayed when the SP11 QoS tracker starts, followed by a second online-CPU scan to close the replay-to-live-hotplug handoff; live CPU hotplug can also recover the current policy when no replay reference is available
• CPU-frequency CREATE and REMOVE notifications track policy lifetime, and stored raw policy pointers are cleared synchronously during REMOVE before the CPU-frequency core can free them
• teardown first prevents new policy attachment, removes the CPU-hotplug instance and dynamic state, sweeps QoS requests and policy slots while the REMOVE notifier is still registered, and unregisters the notifier last
• if CPU frequency is unavailable, including a cpufreq.off=1 boot or notifier-registration failure, only the optional frequency cap is disabled; platform-profile and fan control remain registered
• entering low power applies the CPU cap first, then fan state, and writes TMP last; leaving low power applies fan state first, writes TMP, and releases the cap last
• TMP remains authoritative: a failed transition reads the resulting TMP profile back and reconciles fan and cap state to it; an uncertain readback, or failed fan reconciliation involving low power, retains the conservative low-power cap
• the staging branch's no-op power-supply notifier is not carried

Provenance

All three focused rewrites are authored by Leon Silcott, retain immutable links to their corresponding integration commits, and carry the authorized Signed-off-by: Leon Silcott <leon@boasi.io>.

Validation

• git diff --check e3bd10a401d9..HEAD
• ARM64 ubuntu_x1e_defconfig W=1 builds, with 10 jobs, of drivers/acpi/platform_profile.o, drivers/platform/surface/surface_aggregator_registry.o, and drivers/platform/surface/surface_platform_profile.o
• the same three W=1 object targets build with 10 jobs and CONFIG_CPU_FREQ=n, covering the optional QoS path
• strict checkpatch passes independently on each of the three final rewritten commits with 0 errors, 0 warnings, and 0 checks
• lifecycle audit covers failed ACPI initialization, class registration, legacy attribute creation, notification, and teardown
• QoS audit covers policies present at probe, policies created later, fully offline policies, policy removal, profile-device removal, and property absence
• transition audit covers cap/fan/TMP ordering, post-error TMP readback, fan reconciliation, and conservative capping when state cannot be established safely
• non-SP11 source audit confirms the exact legacy write path and no frequency-cap, default-profile, or transaction change without the Denali-only software-node properties

These are targeted object-build checks. They do not claim a complete kernel package build or a successful standalone module/modpost pass.

Userspace integration

Ubuntu Resolute's stock Power Profiles Daemon 0.30-2 probes only the legacy /sys/firmware/acpi/platform_profile and /sys/firmware/acpi/platform_profile_choices paths. It does not discover the native /sys/class/platform-profile provider added here.

Direct native-sysfs testing is therefore available with this kernel alone, but desktop integration and powerprofilesctl require the pinned companion userspace change or an equivalent backport. That userspace combination must be tested before this PR is marked ready.

Hardware checks still required

• boot this exact branch on both X1E/OLED and X1P/LCD Surface Pro 11 variants and verify the native platform-profile class and fan-speed device enumerate
• on both variants, verify the advertised profile choices, default low-power selection, fan behavior, and the 2.515 GHz ceiling
• switch repeatedly among low-power, balanced, and performance profiles under load, confirming the cap reaches every CPU policy in low power and is released everywhere on exit
• fully offline every CPU in one policy, select low power while that policy is absent, bring it online again, and verify the cap is attached; repeat while leaving low power
• bind and unbind the Surface platform-profile driver repeatedly, checking for stale QoS requests, missing policies, warnings, or use-after-free reports
• tear down and re-register CPU-frequency policies while the profile driver remains bound, in both capped and uncapped profiles
• boot with cpufreq.off=1 and confirm profile selection and fan control still work while no frequency cap is advertised or attempted
• fault-inject TMP writes, fan writes, TMP readback, and fan reconciliation; verify recovered state follows readable TMP and uncertain low-power transitions keep the conservative cap
• suspend and resume in each profile, then repeat transitions, workload, and fully-offline-policy checks
• test direct native sysfs and the pinned companion userspace/backport separately, including desktop controls and powerprofilesctl
• exercise a non-SP11 Surface with an existing SAM platform-profile provider and confirm same-profile writes, profiles, legacy ACPI interface, fan behavior, and CPU-frequency limits remain unchanged