[PATCH 0/7] platform/x86: asus-wmi: expose the firmware fan floor tables

[Bartu Alev]

On some ASUS laptops, the embedded controller enforces minimum fan duties
on custom fan curves (CPU, GPU, and mid fan where present). These limits
are not exposed in curve tables or standard devstate queries. Because the
EC applies max(curve, floor) on each thermal tick, a curve requesting 10%
on a point with a 58% floor runs at 58%, while pwmY_auto_pointZ_pwm still
reports 10%. The thresholds share a similar asymmetry: reads return the
uploaded byte, but the EC clamps the value to the point's temperature
decade before use.

Because firmware never writes enforced floors into the reported curve
buffers, userspace curve utilities like asusctl cannot display
unreachable duty ranges or explain why fans run faster than configured.
This series exposes the firmware floor tables through read-only sysfs
attributes so userspace can inspect the enforced limits.

Hardware analysis:

 - Reverse engineering the FA507 EC firmware shows that duty[i] =
   max(curve[i], floor[i]) is computed on each thermal tick. Point Z
   (1-based) is constrained to the temperature decade [30 + 10 * (Z - 1),
   39 + 10 * (Z - 1)] °C, downward transitions use 5 °C hysteresis, points
   step without interpolation, and thresholds outside the decade are
   clamped on write.

 - Live devmem and DSTS captures on an FA507NV confirm these floor tables:
   CPU {0, 0, 0, 0, 25, 48, 58, 74}% and GPU {0, 0, 0, 0, 26, 57, 68,
   91}%.

 - The read path matches the G614PR DSDT DSFL method, which returns 8
   bytes via the mailbox. Values and band layouts for that family are not
   yet confirmed on hardware. The driver rejects replies shorter than 8
   bytes or containing values above 100%, and warns once if entries
   decrease.

Design notes:

 - Floor attributes are non-standard hwmon extensions: they add a
   read-only, hardware-enforced minimum to the pwmY_auto_pointZ_* family.

 - The series does not clamp user uploads in software. The EC already
   enforces the floor in hardware, and keeping the write path pass-through
   ensures user-configured curves are not rewritten if firmware table
   parsing encounters quirks.

 - Tables refresh after profile changes and curve resets because the EC
   re-runs its defaults reload when the mode byte it keys on changes,
   which a power profile switch can do. On the FA507, floor values
   remain identical across profiles, so this refresh is precautionary for
   other hardware families.

Pre-existing issues noted during development (can be addressed in a
separate series):
 - asus_wmi_evaluate_method_buf() dereferences the return object without a
   NULL check.
 - asus_wmi_remove() frees driver data while the devm-managed hwmon device
   remains accessible.
 - fan_curve_store() updates curves without serializing against
   fan_curve_write().

Questions:

 1. Hardware verification: captures from ROG Zephyrus, ROG Strix, Ally
    or other DSFL-family hardware would confirm values and band layouts
    there. With patch 1 applied:

        echo 0x00110026 > /sys/kernel/debug/asus-nb-wmi/dev_id
        cat /sys/kernel/debug/asus-nb-wmi/dsts

    On a stock kernel, the same reply can be captured with the
    out of tree acpi_call module by evaluating \_SB.ATKD.WMNB with
    method id 0x53545344 and the devid in the argument buffer. Any
    report would be very welcome.

 2. Patch 7 reports effective duty max(stored, floor) on enabled curves.
    Userspace could compute this from the floor attributes;
    is handling this in the driver preferred? or userspace(asusctl)?

 3. Registration API: floor attributes are added to the existing
    asus_custom_fan_curve device via devm_hwmon_device_register_with_groups(),
    matching existing auto_point attributes. The with_info API has no
    auto_point channel, while hwmon.h marks with_groups deprecated.
    Is extending the current group acceptable, or would you prefer
    converting the device to with_info with auto_point attributes carried
    in extra_groups?

 4. Naming: new attributes use pwmY_auto_pointZ_floor_pwm, inserting a
    _floor_ infix into the standard name. Is this naming acceptable?

Signed-off-by: Bartu Alev <bartualev@xxxxxxxxx>
---
Bartu Alev (7):
      platform/x86: asus-wmi: dump buffer replies in the debugfs dsts file
      Documentation: ABI: document the ASUS custom fan curve attributes
      platform/x86: asus-wmi: define the fan floor table DEVIDs
      platform/x86: asus-wmi: read the firmware fan floor tables
      platform/x86: asus-wmi: reject short fan curve replies
      platform/x86: asus-wmi: expose the fan floor tables via hwmon
      platform/x86: asus-wmi: show the effective duty for enabled curves

 Documentation/ABI/testing/sysfs-platform-asus-wmi |  96 ++++++
 drivers/platform/x86/asus-wmi.c                   | 390 +++++++++++++++++++++-
 include/linux/platform_data/x86/asus-wmi.h        |   3 +
 3 files changed, 473 insertions(+), 16 deletions(-)
---
base-commit: 9d3475065167197742b0882aff21cf8e78393277
change-id: 20261101-asus-fan-floors-v4-2aba8ff80b89

Best regards,
--  
Bartu Alev <bartualev@xxxxxxxxx>