Received-SPF: pass (google.com: domain of linux-kernel+bounces-64821-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Armin Wolf <W_Armin@gmx.de>
To: corentin.chary@gmail.com,
	luke@ljones.dev
Cc: hdegoede@redhat.com,
	ilpo.jarvinen@linux.intel.com,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 3/5] platform/x86: wmi: Always evaluate _WED when receiving an event
Date: Wed, 14 Feb 2024 08:04:31 +0100
Message-Id: <20240214070433.2677-4-W_Armin@gmx.de>
In-Reply-To: <20240214070433.2677-1-W_Armin@gmx.de>
References: <20240214070433.2677-1-W_Armin@gmx.de>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:B9+M+kARpvM=;29Yz0UMEfwr9Oh6FW9Ck93D/DSn
 mCOXS5qYb6llM41K65R9sPySimLwwLV9kpMk0rZ1ZRbPDQZ4AaGeJA6OEiR9+ZOGJb5r0CstO
 AyAknHNoPbZqV8lm3aBEcTJa26lN1eG7Z1YeJt8zf5Ft0Ip79CdAWP906tNtoiq8NZiCXXDs2
 ke3DCNMBgZzbajRaLyT6M4TKJ3jrBKexrbcfSgLnnqFVIpY0+/BbDn3EuVIDLp7qkDQpV3IuB
 FflRvIduUra2m859T0d7Cpa15SIgHaqNO76jXv8iIczMokba0CmHeoBJHkxhlbCcC+DKNhyTO
 8qMIlQVKUmAlYBQOQYukFtzJPY1PyIsizJESzCFV/ycSJvme6gXZ9pZQtf4ruAcapuiWABq0w
 JvXovOw3sVk2MDqOdhTsTUzrYy7Rqa8NXMR1udkzNlpcEfPBUx08jtQQzhSnnanK8QOLI3Uav
 qJVWStBMpVP/Pm13GCW753T2XlcbEklOI2/kDQ+6w7ObtXusZuxsgDTLrIDwXclenpA6tK0tv
 +XxO3H29Qp63dydr+ZA8OKskzoUsX8fZcZga6rXGW4oLe0ObJXOJ/wCKSVVZ/ZYDIh1m0icdl
 P8NrxvsHW7P67pWBSZ3vusFclcO2cbyB1Yqmr4Um12bUPjDCCNCISWK4qjuZi6fIR+v0TvrXb
 IBhD59LlBwayERL65Fd8kjT3ZUCCDDA567tlE9ySmzfg44dmLrQHfC/qsgG8T7QEJuU/4wh6g
 a5s7N5O0/5XK+2Y5bjrN3HipvNqqclnxwgAXT/oTn7Mj0UYoSA6yRNQQLo/vIPFj5lnmSADwa
 wlmB+A7T2jvqtHSw/WqOfGue8QZSOl73kUWBzFcZ1l6ss=

The ACPI WMI specification states:

	"The _WED control method is evaluated by the mapper in
	 response to receiving a notification from a control
	 method."

This means that _WED should be evaluated unconditionally even
if no WMI event consumers are present.
Some firmware implementations actually depend on this behavior
by storing the event data inside a queue which will fill up if
the WMI core stops retrieving event data items due to no
consumers being present

Fix this by always evaluating _WED even if no WMI event consumers
are present.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
=2D--
 drivers/platform/x86/wmi.c | 67 ++++++++++++++++++++++++++++----------
 1 file changed, 49 insertions(+), 18 deletions(-)

diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 8a916887c546..8622ce3fecfd 100644
=2D-- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -1207,37 +1207,46 @@ acpi_wmi_ec_space_handler(u32 function, acpi_physi=
cal_address address,
 	}
 }

-static void wmi_notify_driver(struct wmi_block *wblock)
+static int wmi_get_notify_data(struct wmi_block *wblock, union acpi_objec=
t **obj)
 {
-	struct wmi_driver *driver =3D drv_to_wdrv(wblock->dev.dev.driver);
 	struct acpi_buffer data =3D { ACPI_ALLOCATE_BUFFER, NULL };
-	union acpi_object *obj =3D NULL;
 	acpi_status status;

-	if (!driver->no_notify_data) {
-		status =3D get_event_data(wblock, &data);
-		if (ACPI_FAILURE(status)) {
-			dev_warn(&wblock->dev.dev, "Failed to get event data\n");
-			return;
-		}
+	if (test_bit(WMI_NO_EVENT_DATA, &wblock->flags)) {
+		*obj =3D NULL;
+		return 0;
+	}

-		obj =3D data.pointer;
-		if (!obj) {
-			dev_warn(&wblock->dev.dev, "Event contains not event data\n");
-			return;
-		}
+	status =3D get_event_data(wblock, &data);
+	if (ACPI_FAILURE(status)) {
+		dev_warn(&wblock->dev.dev, "Failed to get event data\n");
+		return -EIO;
+	}
+
+	*obj =3D data.pointer;
+
+	return 0;
+}
+
+static void wmi_notify_driver(struct wmi_block *wblock, union acpi_object=
 *obj)
+{
+	struct wmi_driver *driver =3D drv_to_wdrv(wblock->dev.dev.driver);
+
+	if (!obj && !driver->no_notify_data) {
+		dev_warn(&wblock->dev.dev, "Event contains no event data\n");
+		return;
 	}

 	if (driver->notify)
 		driver->notify(&wblock->dev, obj);
-
-	kfree(obj);
 }

 static int wmi_notify_device(struct device *dev, void *data)
 {
 	struct wmi_block *wblock =3D dev_to_wblock(dev);
+	union acpi_object *obj;
 	u32 *event =3D data;
+	int ret;

 	if (!(wblock->gblock.flags & ACPI_WMI_EVENT && wblock->gblock.notify_id =
=3D=3D *event))
 		return 0;
@@ -1247,10 +1256,32 @@ static int wmi_notify_device(struct device *dev, v=
oid *data)
 	 * Because of this the WMI driver notify handler takes precedence.
 	 */
 	if (wblock->dev.dev.driver && wblock->driver_ready) {
-		wmi_notify_driver(wblock);
+		ret =3D wmi_get_notify_data(wblock, &obj);
+		if (ret >=3D 0) {
+			wmi_notify_driver(wblock, obj);
+			kfree(obj);
+		}
 	} else {
-		if (wblock->handler)
+		if (wblock->handler) {
 			wblock->handler(*event, wblock->handler_data);
+		} else {
+			/* The ACPI WMI specification says that _WED should be
+			 * evaluated every time an notification is received, even
+			 * if no consumers are present.
+			 *
+			 * Some firmware implementations actually depend on this
+			 * by using a queue for events which will fill up if the
+			 * WMI driver core stops evaluating _WED due to missing
+			 * WMI event consumers.
+			 *
+			 * Because of this we need this seemingly useless call to
+			 * wmi_get_notify_data() which in turn evaluates _WED.
+			 */
+			ret =3D wmi_get_notify_data(wblock, &obj);
+			if (ret >=3D 0)
+				kfree(obj);
+		}
+
 	}
 	up_read(&wblock->notify_lock);

=2D-
2.39.2