On Wed, 7 Oct 2026, Derek J. Clark wrote: > On October 7, 2026 11:30:00 AM PDT, Rong Zhang wrote: > >Hi Mark, Armin, > > > >于 2026年9月29日 GMT+08:00 01:53:18，Rong Zhang 写道： > >> Hi Mark, > >> > >> Thanks for the information. > >> > >> 于 2026年9月29日 GMT+08:00 00:04:14，Mark Pearson 写道： > >> > > >> > > >> > 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 > >> > > 写道： > >> > >> 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. :-) -- i.