Re: [PATCH 0/2] platform/x86: lenovo-wmi-capdata: Add debugfs file for dumping capdata

[Rong Zhang]

Hi Derek and Kurt,

On Tue, 2026-02-10 at 15:49 -0800, Derek J. Clark wrote:
> On February 10, 2026 3:41:31 PM PST, Kurt Borja <kuurtb@xxxxxxxxx> wrote:
> > On Tue Feb 10, 2026 at 2:19 PM -05, Rong Zhang wrote:
> > > The Lenovo GameZone/Other interfaces have some delicate divergences
> > > among different devices. When making a bug report or adding support for
> > > new devices/interfaces, capdata is the most important information to
> > > cross-check with.
> > > 
> > > Add a debugfs file (lenovo_wmi/<device_name>/capdata), so that users can
> > > dump capdata and include it in their reports.
> > > 
> > > The output is like:
> > > 
> > >   LENOVO_CAPABILITY_DATA_00[0]:
> > >     id:             0x00010000 [dev:  0, feat:  1, mode:  0, type:  0]
> > >     supported:      0x00000007 [ RWV]
> > >     default_value:  0
> > > 
> > >   LENOVO_CAPABILITY_DATA_01[0]:
> > >     id:             0x00000000 [dev:  0, feat:  0, mode:  0, type:  0]
> > >     supported:      0x00000000 [    ]
> > >     default_value:  0
> > >     step:           0
> > >     min_value:      0
> > >     max_value:      0
> > > 
> > >   LENOVO_FAN_TEST_DATA[0]:
> > >     id:             1
> > >     min_rpm:        2200
> > >     max_rpm:        5000
> > > 
> > > A helper function for creating per-devcie debugfs directories is also
> > > introduced into lenovo-wmi-helpers in order that we can maintain a tidy
> > > directory structure in debugfs.
> > > 
> > > The series is based on platform-drivers-x86/review-ilpo-next since it
> > > depends on a commit there. I am OK to wait until the next cycle.
> > > 
> > > Rong Zhang (2):
> > >   platform/x86: lenovo-wmi-helpers: Add helper for creating per-device
> > >     debugfs dir
> > >   platform/x86: lenovo-wmi-capdata: Add debugfs file for dumping capdata
> > > 
> > >  drivers/platform/x86/lenovo/Kconfig       |   1 +
> > >  drivers/platform/x86/lenovo/wmi-capdata.c | 121 ++++++++++++++++++++++
> > >  drivers/platform/x86/lenovo/wmi-capdata.h |   4 +-
> > >  drivers/platform/x86/lenovo/wmi-helpers.c |  34 ++++++
> > >  drivers/platform/x86/lenovo/wmi-helpers.h |   2 +
> > >  5 files changed, 159 insertions(+), 3 deletions(-)
> > > 
> > > 
> > > base-commit: 5a5203a45b063a594e89a2aeaf9e4923893a5b4c
> > 
> > Hi Rong,
> > 
> > This is indeed very useful debug information.
> > 
> > Once you and Derek agree on the approach for this series, I'll add my
> > Tested-by tag.
> > 
> > One more thing though. Can you please explain the "supported" byte? What
> > is `+` and `V` supposed to mean?

"V" means valid. It's consistent with the corresponding macro name.

> Kurt,
> 
> It's enumerated in the patch:
> 
> +       seq_printf(s, "  supported:      0x%08x [%c%c%c%c]\n", cd00->supported,
> +                  extra ? '+' : ' ',
> +                  get   ? 'R' : ' ',
> +                  set   ? 'W' : ' ',
> +                  valid ? 'V' : ' ');
> 
> 
> From the documentation:
> uint32 Capability //7:by project 
> bit 2:  0: not support SetFeatureValue(),  1: support SetFeatureValue() 
> bit 1:  0: not support GetFeatureValue(),  1: support GetFeatureValue()
> bit 0:  0: not support feature,  1: support feature 
> 
> I don't see any examples of the "extra" bit in the docs.

It's not a single bit. Instead, it's printed out when any bit other
than RWV is set. I added this when I recalled the definition of
capability 0x04050000, which has an extra bit defined:

   Fan Test For Diagnostic Software
   uint32 IDs //0x04050000
   uint32 Capability //9:by project
   bit 3: 0: not support LENOVO_FAN_TEST_DATA, 1 support LENOVO_FAN_TEST_DATA
   bit 2: 0: not support SetFeatureValue(), 1: support SetFeatureValue()
   bit 1: 0: not support GetFeatureValue(), 1: support GetFeatureValue()
   bit 0: 0: not support fan test for diagnostic software, 1: support an test for diagnostic software

(from https://lore.kernel.org/r/CAFqHKTkOZUfDb8cGbGnVPCS9wNbOBsiyOk_MkZR-2_Za6ZPMng@xxxxxxxxxxxxxx/ )

I assume extra bits are not standardized, and some (current or future)
capabilities may have multiple extra bits defined. Hence, I simply
named it "+". After all, it's just a reminder for us to check the
documentation (I don't have any, though).

Thanks,
Rong

> Thanks,
> Derek