[RFC] platform/x86: ideapad-laptop: Question about exposing DYTC GK/aggressive fan mode on Lenovo 83LR

[M K]

Hi,

I am investigating the Lenovo XiaoXin Pro 14 ASP10 / IdeaPad Pro 5 14ASP10
(DMI product name 83LR, BIOS QKCN29WW) on Linux, and I would like to ask
for guidance before preparing a patch.

This machine exposes the standard IdeaPad DYTC platform profiles through
drivers/platform/x86/lenovo/ideapad-laptop.c, and Linux currently maps them
to:

  low-power
  balanced
  performance

However, this machine also has an additional DYTC-controlled mode that is
not currently exposed by ideapad-laptop. This may not be specific to this
single 83LR machine; similar XiaoXin / IdeaPad models may expose comparable
vendor modes through DYTC.

What I have verified on hardware:

  - The Lenovo WMI GameZone path is not usable on this machine.
    The GameZone GUID is present, but lenovo_wmi_gamezone still fails to
    probe. On this machine, the related WMAA methods 43/44/45 all return
    0x0.

  - The usable control path is DYTC.

  - Evaluating the DYTC ACPI method (specifically \_SB.PCI0.LPC0.EC0.VPC0.DYTC)
    with 0x11100b enables an additional mode. In the ACPI SSDT tables, this
    command triggers the TCAM(0x1E) branch, which calls DUGK(). This appears
    to be the vendor's Geek ("GK") mode, which is an aggressive fan mode.

  - Evaluating DYTC with 0x100b, followed by 0x1ff, exits this Geek mode and
    returns the machine to the ordinary performance profile.

  - Under sustained external load, ordinary performance mode stabilizes at:
      DYTC get = 0x8012b01
      fan1/fan4 = 5200 / 4900 RPM
      package power about 55.3W - 65.0W

  - Under the additional Geek/GK mode:
      DYTC get = 0x801f001
      fan1/fan4 = 6200 / 5900 RPM
      package power about 55.8W - 63.2W

In the SSDT tables, DUGK() programs more aggressive CSPL/CPPL values than
DUPF() used by the standard performance mode. For example, the BOL0==1
paths use CSPL=0x4B/0x48 and CPPL=0x55 in DUGK(), versus CSPL=0x41 and
CPPL=0x41 in DUPF(). However, under sustained load in Linux, the measured
package power limits do not exceed 63-65W in either mode, likely due to
APMF or platform thermal throttling. Thus, the main observable effect of
this mode under Linux is a much more aggressive fan curve.

The open design question is how this should be represented in Linux.
The options I can see are:

  1. Expose it via platform_profile, for example as "max-power" or "custom"
     on affected DMI-matched systems. Note that mapping it back from DYTC
     status is slightly tricky because the DYTC get return value (0x801f001)
     has its mode bits set to 0xF (same as balanced), meaning it must be
     distinguished by a raw value check or driver state tracking.

  2. Expose it via a Lenovo-specific sysfs / firmware attribute, since it
     behaves more like a vendor-specific aggressive fan mode than a generic
     performance profile under Linux.

  3. Start with a smaller patch that only detects and reports this mode,
     without adding a new writable userspace interface yet.

Does one of these directions sound acceptable for platform-drivers-x86?
I am happy to prepare and test a patch once the preferred direction is
clear.

If helpful, I can also send:

  - full DMI information
  - the measured DYTC state transitions
  - the controlled RPM / power comparison logs
  - the WMI/GameZone failure details

Thanks,
mkaros