On Sun, May 25, 2025 at 2:42 PM Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx> wrote: > > On Mon, 26 May 2025, Ilpo Järvinen wrote: > > > On Wed, 21 May 2025, Derek J. Clark wrote: > > > > > Adds support for the Lenovo "Gaming Series" of laptop hardware that use > > > WMI interfaces that control various power settings. There are multiple WMI > > > interfaces that work in concert to provide getting and setting values as > > > well as validation of input. Currently only the "Gamezone", "Other > > > Mode", and "LENOVO_CAPABILITY_DATA_01" interfaces are implemented, but > > > I attempted to structure the driver so that adding the "Custom Mode", > > > "Lighting", and other data block interfaces would be trivial in later > > > patches. > > > > > > This driver attempts to standardize the exposed sysfs by mirroring the > > > asus-armoury driver currently under review. As such, a lot of > > > inspiration has been drawn from that driver. > > > https://lore.kernel.org/platform-driver-x86/20250319065827.53478-1-luke@xxxxxxxxxx/#t > > > > > > The drivers have been tested by me on the Lenovo Legion Go and Legion Go > > > S. > > > > > > Suggested-by: Mario Limonciello <superm1@xxxxxxxxxx> > > > Reviewed-by: Armin Wolf <W_Armin@xxxxxx> > > > Signed-off-by: Derek J. Clark <derekjohn.clark@xxxxxxxxx> > > > --- > > > v11: > > > - Fix formmating issues. > > > > Thanks for the update, I've applied this now into the review-ilpo-next > > branch. BUT, this is very late in the cycle now and if there's a build > > issue (or LKP doesn't build test it in reasonable time), I'll have to drop > > this series and postpone it into the next cycle as I don't want to delay > > the main PR to Linus too long. > > > > But lets hope for the best, I think some depends on issues were fixed > > earlier (IIRC), so hopefully it works good enough now. :-) > > Hmpf, these give me a few new warnings related to this series: > > make W=1 drivers/platform/x86/ > make C=2 drivers/platform/x86/ When I use scoped_guard the warnings go away. It seems to be a limitation of sparse in that its not correctly identifying the guard will be unlocked on the return perhaps? In any case, if you're okay with a scoped guard here (matches both other invocations) I'll send it up. I also took care of the warnings for W=1. > ...I really don't know why sparse complains about the lock context > imbalance though, those functions use guard(). > > There's also a copy-paste error: > > * lwmi_gz_profile_get_get() - Get the current platform profile. > > ..._get_get -> ..._set > Get -> Set > > > > -- > i.
