Re: [PATCH 0/9] platform/x86: lenovo-wmi-{other,capdata,helpers}: Improve robustness on buggy firmware

[Mark Pearson]

On Thu, Oct 8, 2026, at 7:47 AM, Ilpo Järvinen wrote:
> On Thu, 8 Oct 2026, Rong Zhang wrote:
>
>> Hi Ilpo,
>> 
>> On Wed, 2026-10-07 at 23:54 +0300, Ilpo Järvinen wrote:
>> > On Wed, 7 Oct 2026, Derek J. Clark wrote:
>> > 
>> > > On October 7, 2026 11:30:00 AM PDT, Rong Zhang <i@xxxxxxxx> wrote:
>> > > > Hi Mark, Armin,
>> > > > 
>> > > > 于 2026年9月29日 GMT+08:00 01:53:18，Rong Zhang <i@xxxxxxxx> 写道：
>> > > > > Hi Mark, 
>> > > > > 
>> > > > > Thanks for the information. 
>> > > > > 
>> > > > > 于 2026年9月29日 GMT+08:00 00:04:14，Mark Pearson <mpearson-lenovo@xxxxxxxxx> 写道：
>> > > > > > 
>> > > > > > 
>> > > > > > On Sat, Sep 26, 2026, at 11:01 PM, Rong Zhang wrote:
>> > > > > > > Hi Navon,
>> > > > > > > 
>> > > > > > > Thanks a lot for your test. 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 于 2026年9月27日 GMT+08:00 05:04:15，Navon John Lukose 
>> > > > > > > <navonjohnlukose@xxxxxxxxx> 写道：
>> > > > > > > > Tested on a Yoga Pro 7 14IAH10 (83KF, BIOS QGCN35WW). Neither mainline
>> > > > > > > > nor the series binds here. This firmware has no
>> > > > > > > > LENOVO_CAPABILITY_DATA_01 in _WDG at all, so no component ever
>> > > > > > > > registers for that match and lwmi_om_master_bind() never runs. Skipping
>> > > > > > > > the match for GUIDs the firmware doesn't declare fixes it:
>> > > > > > > > 
>> > > > > > > > diff --git a/drivers/platform/x86/lenovo/wmi-capdata.c b/drivers/platform/x86/lenovo/wmi-capdata.c
>> > > > > > > > index 805e36ef7..d64520be1 100644
>> > > > > > > > --- a/drivers/platform/x86/lenovo/wmi-capdata.c
>> > > > > > > > +++ b/drivers/platform/x86/lenovo/wmi-capdata.c
>> > > > > > > > @@ -76,11 +76,13 @@ enum lwmi_cd_type {
>> > > > > > > >  #define LWMI_CD_TABLE_ITEM(_type)		\
>> > > > > > > >  	[_type] = {				\
>> > > > > > > >  		.name = #_type,			\
>> > > > > > > > +		.guid = _type##_GUID,		\
>> > > > > > > >  		.type = _type,			\
>> > > > > > > >  	}
>> > > > > > > >  
>> > > > > > > >  static const struct lwmi_cd_info {
>> > > > > > > >  	const char *name;
>> > > > > > > > +	const char *guid;
>> > > > > > > >  	enum lwmi_cd_type type;
>> > > > > > > >  } lwmi_cd_table[] = {
>> > > > > > > >  	LWMI_CD_TABLE_ITEM(LENOVO_CAPABILITY_DATA_00),
>> > > > > > > > @@ -166,6 +168,14 @@ void lwmi_cd_match_add_all(struct device *master, struct component_match **match
>> > > > > > > >  		if (lwmi_cd_table[i].type == LENOVO_FAN_TEST_DATA)
>> > > > > > > >  			continue;
>> > > > > > > >  
>> > > > > > > > +		/*
>> > > > > > > > +		 * Some firmware does not declare every capdata GUID at all, in
>> > > > > > > > +		 * which case no component would ever register for it and the
>> > > > > > > > +		 * master could never bind.
>> > > > > > > > +		 */
>> > > > > > > > +		if (!wmi_has_guid(lwmi_cd_table[i].guid))
>> > > > > > > > +			continue;
>> > > > > > > 
>> > > > > > > This was exactly what I did in the earlier revision while I was 
>> > > > > > > introducing the support for capdata00 and capdata_fan.
>> > > > > > > 
>> > > > > > > The wmi_has_guid() approach was eventually replaced by the 
>> > > > > > > sub-component approach, because the use of the former is strongly 
>> > > > > > > discouraged.
>> > > > > > > 
>> > > > > > > In the next revision I am going to convert capdata01 into a 
>> > > > > > > sub-component, too. In this manner some heavy and complex work in the 
>> > > > > > > series will become needless and can be simplified. While the 
>> > > > > > > sub-component approach itself is complex, we've had the infrastructure 
>> > > > > > > to make it work. Therefore wiring it up should be a trivial work.
>> > > > > > > 
>> > > > > > > Mark, Derek,
>> > > > > > > 
>> > > > > > > Do you know if there is any way to determine the existence of capdata01 
>> > > > > > > using capdata00? 
>> > > > > > > 
>> > > > > > Note that I can see I'm afraid
>> > > > 
>> > > > So there is no way to determine the existence of capdata01 using capdata00, correct?
>> > > > 
>> > > > > > 
>> > > > > > I'm guessing the patch Armin posted on my thread "[RFC PATCH 5/7] platform/x86: think-lmi: Initial ThinkLMI v2 driver" to check if it exists won't help here?
>> > > > > 
>> > > > > After some consideration, it seems that we don't really need to determine the existence of capdata01 if we take the sub-component approach, thanks to the fact that every functionality either depends on capdata00 or depends on capdata01, but never both.
>> > > > 
>> > > > Unfortunately, it turned out that it can't resolve the issue by simply converting capdata01 into a sub-component, unless a virtual device is also created to split the component matching list into two, which is more like a dirty workaround.
>> > > > 
>> > > > So yeah, the series needs the wmidev_exists() patch from Armin. 
>> > > > Considering that the ThinkLMI v2 series is probably still at the RFC 
>> > > > stage, do you mind if I integrate the wmidev_exists() patch into my 
>> > > > series? 
>> > > 
>> > > Rong/Mark,
>> > > 
>> > > My $0.02, I don't think it matters who sends it up. If Ilpo is okay with 
>> > > it of course, both series should include it as a prerequisite 1/X and 
>> > > whichever gets picked up first will get into next. Then that patch can 
>> > > be omitted from the other series when it gets picked. That way both 
>> > > series will build if you apply the mbox onto next until one is merged.
>> > 
>> > Hi,
>> > 
>> > For me it's fine either way:
>> > 
>> > 1) Have the same patch in both series.
>> > 
>> > 2) If we know for sure we need the API anyway, just add it as a standalone 
>> > in advance.
>> > 
>> > I suppose 2 would be slightly simpler but it's up to you which way you 
>> > prefer.
>> > 
>> > Lets not make things more complicated than they have to be. :-)
>> 
>> Thanks for you suggestion.
>> 
>> The v2 patch is almost ready, and I will submit it today or tomorrow. It
>> will anyway depend on the wmidev_exists() patch to build, so I'd prefer
>> 1.
>> 
>> Or we can combine 1 and 2 -- do a subset apply with the wmidev_exists()
>> patch if it looks good but my v2 series has issues. Then Mark and I can
>> rebase and resubmit.
>
> I've no problem in taking only a part of series as needed, if you prefer 
> that.
>
> Armin had something to say about the interface but I suppose you saw that 
> already.
>

I'm still a bit away from having it ready on my side so Rong, go for it (with Armin's original - I'll just have to refactor to handle that)

Mark