public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: "Kurt Borja" <kuurtb@gmail.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Hans de Goede" <hansg@kernel.org>
Cc: platform-driver-x86@vger.kernel.org, Dell.Client.Kernel@dell.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] platform/x86: alienware-wmi-base: Transition to new WMI API
Date: Wed, 29 Apr 2026 23:19:38 +0200	[thread overview]
Message-ID: <f1bd031d-b6a6-44fe-b22e-c0d6ea5e5fb0@gmx.de> (raw)
In-Reply-To: <DI5O65UZ12EU.1IC2SMB4DGNWA@gmail.com>

Am 29.04.26 um 15:23 schrieb Kurt Borja:

> On Tue Apr 28, 2026 at 2:27 PM -05, Armin Wolf wrote:
>> Am 28.04.26 um 18:37 schrieb Kurt Borja:
>>
>>> Transition to the new wmi_buffer based WMI API.
>>>
>>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>>> ---
>>> v4:
>>>     - Rebase to use the new wmidev_invoke_method() with size check
>>>
>>> v3: https://patch.msgid.link/20260331-aw-new-api-v3-1-ef03b94529d8@gmail.com
>>>     - Use __free() instead of manual cleanup.
>>>     - Include <linux/types.h>
>>>
>>> v2: https://patch.msgid.link/20260331-aw-new-api-v2-1-3b0d33bf8d22@gmail.com
>>>     - Cast wmi_buffer data to __le32 and then use le32_to_cpu() before
>>>       returning
>>>
>>> v1: https://patch.msgid.link/20260330-aw-new-api-v1-1-95910bfa1b38@gmail.com
>>> ---
>>>    drivers/platform/x86/dell/alienware-wmi-base.c | 31 ++++++++++++++++----------
>>>    1 file changed, 19 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/platform/x86/dell/alienware-wmi-base.c b/drivers/platform/x86/dell/alienware-wmi-base.c
>>> index 64562b92314f..21d3acfbd73d 100644
>>> --- a/drivers/platform/x86/dell/alienware-wmi-base.c
>>> +++ b/drivers/platform/x86/dell/alienware-wmi-base.c
>>> @@ -12,8 +12,13 @@
>>>    #include <linux/cleanup.h>
>>>    #include <linux/module.h>
>>>    #include <linux/platform_device.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/types.h>
>>>    #include <linux/dmi.h>
>>>    #include <linux/leds.h>
>>> +
>>> +#include <asm/byteorder.h>
>>> +
>>>    #include "alienware-wmi.h"
>>>    
>>>    MODULE_AUTHOR("Mario Limonciello <mario.limonciello@outlook.com>");
>>> @@ -150,21 +155,23 @@ u8 alienware_interface;
>>>    int alienware_wmi_command(struct wmi_device *wdev, u32 method_id,
>>>    			  void *in_args, size_t in_size, u32 *out_data)
>>>    {
>>> -	struct acpi_buffer out = {ACPI_ALLOCATE_BUFFER, NULL};
>>> -	struct acpi_buffer in = {in_size, in_args};
>>> -	acpi_status ret;
>>> +	struct wmi_buffer out, in = {
>>> +		.data = in_args,
>>> +		.length = in_size,
>>> +	};
>>> +	int ret;
>>>    
>>> -	ret = wmidev_evaluate_method(wdev, 0, method_id, &in, out_data ? &out : NULL);
>>> -	if (ACPI_FAILURE(ret))
>>> -		return -EIO;
>>> -
>>> -	union acpi_object *obj __free(kfree) = out.pointer;
>>> +	if (out_data)
>>> +		ret = wmidev_invoke_method(wdev, 0, method_id, &in, &out,
>>> +					   sizeof(*out_data));
>>> +	else
>>> +		ret = wmidev_invoke_method(wdev, 0, method_id, &in, NULL, 0);
>>> +	if (ret)
>>> +		return ret;
>>>    
>>>    	if (out_data) {
>>> -		if (obj && obj->type == ACPI_TYPE_INTEGER)
>>> -			*out_data = (u32)obj->integer.value;
>>> -		else
>>> -			return -ENOMSG;
>>> +		__le32 *data __free(kfree) = out.data;
>>> +		*out_data = le32_to_cpu(*data);
>>>    	}
>> Hi,
>>
>> calling wmidev_invoke_method() with a NULL output buffer will likely lead to crashes. This happens
>> because wmidev_invoke_method() demands that a valid pointer to a output buffer is provided by the
>> caller. I suggest that you use wmidev_invoke_procedure() instead:
>>
>> 	__le32 *data __free(kfree) = NULL;
>>
>> 	if (!out_data)
>> 		return wmidev_invoke_procedure(wdev, 0, method_id, &in);
>>
>> 	ret = wmidev_invoke_method(wdev, 0, method_id, &in, &out, sizeof(*data));
>> 	if (ret < 0)
>> 		return ret;
>>
>> 	result = out.data
>> 	...
> Hi Armin,
>
> You're right, I thought the only difference between _procedure and
> _method was the size check.
>
> Also, Sashiko [1] reported that out.data might be ZERO_SIZE_PTR even if
> wmidev_invoke_method() succeeds. I thought it was a false positive but I
> looked further and it was actually a bug. I submitted a fix for this.

Thank you, i will take a look at it immediately.

Thanks,
Armin Wolf

>
> [1] https://sashiko.dev/#/patchset/20260428-aw-new-api-v4-1-d2c06241d7ad%40gmail.com
>

      reply	other threads:[~2026-04-29 21:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-28 16:37 [PATCH v4] platform/x86: alienware-wmi-base: Transition to new WMI API Kurt Borja
2026-04-28 19:27 ` Armin Wolf
2026-04-29 13:23   ` Kurt Borja
2026-04-29 21:19     ` Armin Wolf [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f1bd031d-b6a6-44fe-b22e-c0d6ea5e5fb0@gmx.de \
    --to=w_armin@gmx.de \
    --cc=Dell.Client.Kernel@dell.com \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=kuurtb@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox