Received: by 2002:ab2:1149:0:b0:1f3:1f8c:d0c6 with SMTP id z9csp2644564lqz; Wed, 3 Apr 2024 04:40:28 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWPJlPQvoZVEDfmcAvRW8cjEfiT6P5AeJ4diGCKBfuUHu65Lz3yHr8jYyiB16eOQM63bs5nqtLC1zMUSGIdehWcQgc+ctxJYSdtzTVIbQ== X-Google-Smtp-Source: AGHT+IHwfvOOFHytLkWmnbRkPlidog+B5sO8Ja9rbjDPejyK2Zz6oC78Y7+z9qsJWyLwii7mXl2G X-Received: by 2002:a17:90a:a597:b0:29b:f6c1:cf01 with SMTP id b23-20020a17090aa59700b0029bf6c1cf01mr13028334pjq.40.1712144428121; Wed, 03 Apr 2024 04:40:28 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712144428; cv=pass; d=google.com; s=arc-20160816; b=fTtbEET2KAFzH/fv0cVYpo++uumV/kjaX3KFUXqcsM27xWZcIlkcc76Mi+zPHE+Mfo jPU/TI3WF3pf5vBLndhR+hdq1p7d101Y4ozsgypVA/nM/EkQizpehfm7mug4tneJhtIf Ifuwph9VVblPO7/nNd14Ff6UqSnXdBqJu08aSZRacedalHtkdZHguZQDkP0ZUIk35c8c hEZRX4wk5pmrhS4Ccrbm8UkpQUMyDIVc4G4SWaD1JKT14WX04YyyOqieKW/6PG/ToKiS UHwAMXGRd/D1qfNTG/QIxWla/vzlpSxjLzk9LlPey1PTodL6m9fnYA8zoDX7fKc13BrJ BVFw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:in-reply-to:subject:cc:to:date:from :dkim-signature; bh=NI/GhXZjD8gwo/T4lK26PqhqyPFSFGFAucBTgGM8/S8=; fh=sN1WJ2IpqaHdhylp7IU/vfI4n2BZ14d9aTbF1qrel5Q=; b=xyg0xJ/UZmRnMA6TrN0wlLYscCsda0iBWg2kviNJmu3iFoBBx2awza00w5S9joC2eP 3ahgnCJ88DdjF5Yo7/WpCuQPprWmq4PHZdB9zVFuCFQqVdCbEjTT/A9zJHU5tTM6Dlze A2Ihv59nD9mty3PctCA+8blJPU7rpeIn2SofQv6IVkrEp0OGBOgQwAkxRpCjYlebEksf vAaB8DRGVXTAm1DI4LUr8ODcT1/b9yhyDtDh7N3FmJbpd3J9Vsx1O83QnYedk4hGldLx m5lgf+lk4r2t3ziq6YAzcmurr5Qk0BhWYWDy2OrOGdQN9JZ5Tvh9V2hKTCWMTj0jT2e3 c/8A==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Cz+GR88/"; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-129335-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-129335-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id x8-20020a17090a8a8800b002a20de331besi11885102pjn.127.2024.04.03.04.40.27 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 04:40:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-129335-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Cz+GR88/"; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-129335-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-129335-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 0357D289EA4 for ; Wed, 3 Apr 2024 08:31:58 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1BF176E61A; Wed, 3 Apr 2024 08:31:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Cz+GR88/" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC11C44C8C; Wed, 3 Apr 2024 08:31:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712133083; cv=none; b=UMUtt0Zb542jaNANEKaYqYBhCNoEM6VHIFI0DoZS+Hn0S2V/CmQbehoQOfiLSIjFFKYq/zAREdiX+593HC8RvcRr/ZWJZF+emjnuPMPTmdYVyrEVCi4HaUxik3NI4LIKO0PreVO9QzHe9m9pamBOepfX58RJNjyV6xFaEIoeGPQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712133083; c=relaxed/simple; bh=RqJyN0hEVHVjcA8Rbw9SFpPLwpA2ggCDucLROXLaXQ4=; h=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=nV8QVvexYwAHDpOVzRHuwIWtsQ2OmqSKQCq6KPcHSaoz3ww/ASqUVIcU8Pse99DNWnXwhWh+H+MmCr9o5dvRA3XOT3+FkEYYT8fB59Ti8psx31ZkGRCAeZkkaguooZxLvd+5Zr1ZdJGd2/Ssle5Lzz72gesbTiVHFhAszqu5vzU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Cz+GR88/; arc=none smtp.client-ip=198.175.65.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712133082; x=1743669082; h=from:date:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=RqJyN0hEVHVjcA8Rbw9SFpPLwpA2ggCDucLROXLaXQ4=; b=Cz+GR88/fjWWCKV0GjyMSNfleXAwL63pKweMVHuL88/TFY6Y4izr6YnR MCstiGpG9etDR6+5COt8psUqePUoVqp3DC2hFRmi3iC2wltAE3gMorwU6 8UGj6upsd8nuzQ/0R60KHuDgPeTxKUUlWqs4oYYaK86rC/IERCpkj51YL x3NrwSgmyy94bsQuZFTEA+mXfXZGwJ1lwMeIBJEbuUG60OvqJquZkU1wr lMhI6S6eAI1RW7T+gd15WqVncvkhuj27pNkDxHhQrsiDFltMBTwr/F0MV +CpSRn2jHx5xAJK5+g+oGfj+9nJ8v8uIoijAbFpSdAqHHXBHOU1s3NJcl w==; X-CSE-ConnectionGUID: KWdGFPKIROaXnGA7rHzfiQ== X-CSE-MsgGUID: NziOSNovSYSC4HbJG3FHjQ== X-IronPort-AV: E=McAfee;i="6600,9927,11032"; a="18793076" X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18793076" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 01:31:21 -0700 X-CSE-ConnectionGUID: NHfEeCZOQ1SykuOzeFUjsg== X-CSE-MsgGUID: iWbmClEmQQaHdHi5bL9GaQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18398328" Received: from ijarvine-desk1.ger.corp.intel.com (HELO localhost) ([10.245.247.24]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 01:31:19 -0700 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Date: Wed, 3 Apr 2024 11:31:14 +0300 (EEST) To: Luke Jones cc: Hans de Goede , corentin.chary@gmail.com, platform-driver-x86@vger.kernel.org, LKML Subject: Re: [PATCH v2 8/9] platform/x86: asus-wmi: Add support for MCU powersave In-Reply-To: <24071185.4csPzL39Zc@fedora> Message-ID: <42f09e54-5669-2242-28db-240405e7c4bc@linux.intel.com> References: <20240402022607.34625-1-luke@ljones.dev> <20240402022607.34625-9-luke@ljones.dev> <71426f4c-a44a-cf87-7045-b3f2b3fc240e@linux.intel.com> <24071185.4csPzL39Zc@fedora> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-687975693-1712133074=:1449" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-687975693-1712133074=:1449 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 3 Apr 2024, Luke Jones wrote: > On Wednesday, 3 April 2024 12:01:15=E2=80=AFAM NZDT Ilpo J=C3=A4rvinen wr= ote: > > On Tue, 2 Apr 2024, Luke D. Jones wrote: > > > Add support for an MCU powersave WMI call. This is intended to set th= e > > > MCU in to a low-power mode when sleeping. This mode can cut sleep pow= er > > > use by around half. > > >=20 > > > Signed-off-by: Luke D. Jones > >=20 > > Hi, > >=20 > > I fail to follow the logic of the patch here. This patch makes it > > configurable which is not bad in itself but what is the reason why a us= er > > would not always want to cut sleep power usage down? So this sounds lik= e a > > feature that the user wants always enabled if available. > >=20 > > So what are the downsides of enabling it if it's supported? >=20 > Honestly, I'm not sure. Previously it was a source of issues but with rec= ent=20 > bios and more work in the various gaming-handheld distros it's much less = of a=20 > problem. The issue before was that the MCU would appear every second susp= end=20 > due to the suspend sequence being more parallel compared to windows being= =20 > sequential - the acpi calls related to this would "unplug" the USB device= s=20 > that are related to the n-key (keyboard, same internal dev as laptops) an= d not=20 > complete it before suspend. And then on resume it was unreliable. >=20 > I worked around this by calling the unplug very early, and trying to "plu= g"=20 > super early also so that subsystems wouldn't notice the absence of the de= vice=20 > and create new devices + paths on add. Most of the requirement for that c= ame=20 > from some userspace programs unable to handle the unplug/plug part, but a= lso=20 > bad device state occurring. >=20 > But now with the forced wait for the device to finish its task, and then = the=20 > forced wait before letting it add itself back everything is fine - althou= gh it=20 > does mean everything sees a device properly unplugged and plugged. >=20 > All of the above is to say that the "powersave" function was also part of= the=20 > issue as delayed things further and we couldn't add the device back befor= e=20 > subsystems noticed. >=20 > Distros like bazzite and chimeraOS are now using this patch, and I'd like= to=20 > leave it to them to set a default for now. If it turns out everything is= =20 > indeed safe as houses then we can adjust the kernel default. >=20 > A side-note I think is that because there is a forced wait time due to un= able=20 > to use the right acpi path, the old excuse of "but users might want the d= evice=20 > to wake faster by turning off powersave" doesn't really apply now. >=20 > I will discuss with the main stakeholders, but for now can we accept as i= s? If=20 > changes are required we'll get them done before the merge window. Yes, I think it is okay to make it configurable first and then look=20 separately into making it default on. --=20 i. --8323328-687975693-1712133074=:1449--