Re: [RFC PATCH 3/3] platform/x86: lenovo: Add Legion Go Fan Method curve driver

[Aditya]

Hi Derek,

Thanks for the review.

I have been investigating the BIOS of a sample of devices, which can be
broadly classified as follows:

- Do not have Fan Method
  - 8JCN - Legion Y530-15ICH
  - BHCN - Legion Y540, Y545, and Y7000 2019 families

- Have Fan Method
  - Do not have Method 5 / stub
    - K1CN - Legion 7 16IAX7, Legion Y9000K IAX7
    - JVCN - Yoga Slim 7 ProX 14ARH7

  - Have Method 5
    - Take direct input for Method 6
      - All Legion Go, Go 2, Go S (N3CN, RRCN, RQCN, QCCN, S0CN)

    - Take index based input for Method 6
      - Have Method 5 SensorTable equal to Method 5 FanTable
        - M3CN - Legion Slim 5 16APH8, 16ARH8
        - LYCN - LOQ 15APH8, 16APH8
        - R3CN - LOQ 15IRX10, 17IRX10; G5000 IRX10
        - R8CN - LOQ 15AHP10

      - Have Method 5 SensorTable be all zeros
        - N2CN - Legion Pro 7 16IRX9H; Legion Y9000P IRX9H
        - LPCN - Legion Pro 5 16ARX8, Pro 7 16ARX8H, R9000P ARX8
          variants
        - KWCN - Legion Pro 5 16IRX8, Pro 7 16IRX8/16IRX8H, Y9000P
          IRX8 variants
        - MHCN - Legion 9 16IRX8
        - RYCN - Legion 5 15AKP10; R7000 AKP10
        - Q8CN - LOQ 15IAX9E
        - Q7CN - Legion Pro 7 16IAX10H; Y9000P IAX10
        - RZCN - Legion 9 18IAX10; Legion NX IAX10
        - RGCN - Legion 5 15AHP10; R7000 AHP10
        - RECN - Legion Pro 5 16AFR10; R7000P/R9000P AFR10 variants

For the direct based families, there is no actual discriminator or
value that can tell that the devices take direct input. There are two
possible discriminators I have found so far:
  - SensorTable contains 10, 20, 30, ..., 100 exactly
  - Their Fan Table GUID read function is a stub
    - However the Legion Go 1 does not conform to this, therefore it
      has to become a quirk.

None of the direct based families expose any information on the range of
each point on the curve. 0-100 can be taken as the nominal range.

For the index based families, Legion drivers send the current power tier
(current_mode) as the first Method 6 byte. However, this value comes from
the Other Mode GUID.

All families can use FanTableSize and SensorTableSize for their respective
Method 5 arrays. FanTableSize can be used for the Method 6 array size.

Then, based on this power tier, the respective Fan Table GUID table is
accessed. FanTable_Len for that table determines the range of each point
for Method 6. Each index will be within 1..FanTable_Len.

None of the reviewed Method 6 implementations consume SensorTable values.

The driver should not read back Method 6. Consumers can use Method 5 if they
need to confirm the result.

The Other Mode GUID for these families did not seem to have a fan table
route through it. Only Full Speed and individual fan speed controls were
found here. The firmware based fan curve remains under Fan Method 5/6.

Regarding individual fan speed controls, they did not work on my Legion
Go 1 device. Submitting RPM to it does not change the RPM. The EC fields
which take this input are not exposed to any WMI interface as far as I
have seen on the Legion Go 1.

This also cannot replace firmware based fan curves as it will require a
userspace driver to continuously monitor temperature and set RPM.

Some open questions:

- How should the Other Mode dependency be resolved? Should it be a helper
  in Fan Method, or should Fan Method be incorporated directly?
- What should be the discriminator for direct based families?

Thanks,
Aditya