+ Cc sparse people. On Fri, 30 May 2025, Derek John Clark wrote: > 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. Okay, not that it helps much because the implementation of guard() and scoped_guard() is dramatically different. > It seems to be a > limitation of sparse in that its not correctly identifying the guard > will be unlocked on the return perhaps? It's odd because we'd have those warnings all over the place if it would be general thing for sparse to not understand how guard() works. Maybe sparse people have some idea what's so special here? To give context to sparse people, this patch triggers two false positives in sparse: https://lore.kernel.org/platform-driver-x86/20250522015350.471070-6-derekjohn.clark@xxxxxxxxx/ $ make C=2 drivers/platform/x86/lenovo-wmi-gamezone.o CHECK scripts/mod/empty.c CALL scripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CHECK drivers/platform/x86/lenovo-wmi-gamezone.c drivers/platform/x86/lenovo-wmi-gamezone.c:155:12: warning: context imbalance in 'lwmi_gz_profile_get' - different lock contexts for basic block drivers/platform/x86/lenovo-wmi-gamezone.c:206:12: warning: context imbalance in 'lwmi_gz_profile_set' - different lock contexts for basic block https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/tree/drivers/platform/x86/lenovo-wmi-gamezone.c?h=review-ilpo-next#n190 (That code link is just for convinience, it's not a perma one, I'll be overwriting that branch eventually once the merge window is over, if not sooner.) > In any case, if you're okay > with a scoped guard here (matches both other invocations) I'll send it > up. I'd prefer to keep using guard() for now as this looks clearly a false positive from sparse, not a problem in your code. > I also took care of the warnings for W=1. Thanks. > > ...I really don't know why sparse complains about the lock context > > imbalance though, those functions use guard(). -- i.
