From: Werner Sembach <wse@tuxedocomputers.com>
To: "Armin Wolf" <W_Armin@gmx.de>,
"Hans de Goede" <hdegoede@redhat.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: bentiss@kernel.org, dri-devel@lists.freedesktop.org,
jelle@vdwaa.nl, jikos@kernel.org, lee@kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, miguel.ojeda.sandonis@gmail.com,
ojeda@kernel.org, onitake@gmail.com, pavel@ucw.cz,
platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices
Date: Sat, 28 Sep 2024 09:36:53 +0200 [thread overview]
Message-ID: <cc7f3a74-5cb3-4e53-a941-2fc907c765f1@tuxedocomputers.com> (raw)
In-Reply-To: <0787a2ca-7d77-49ea-8607-a91fdac53d49@gmx.de>
Hi Armin,
Am 27.09.24 um 19:15 schrieb Armin Wolf:
> [...]
> If so, please mark your patches as "RFC" if they are not considered as
> a potentially "final" release.
> Otherwise they might get accepted with the debug printing still inside.
Talking about noob mistakes ... I'm sorry, will do this with the next patch.
>
>>>
>>>> +
>>>> + mutex_lock(&driver_data->wmi_access_mutex);
>>>
>>> Does the underlying ACPI method really require external locking? If
>>> not, then please remove this mutex.
>> Taken from the out of tree driver written by Christoffer, I will ask
>> him about this.
>>>
>>>> + acpi_status status = wmidev_evaluate_method(wdev, 0,
>>>> wmi_method_id, &acpi_buffer_in,
>>>> + &acpi_buffer_out);
>>>> + mutex_unlock(&driver_data->wmi_access_mutex);
>>>> + if (ACPI_FAILURE(status)) {
>>>> + pr_err("Failed to evaluate WMI method.\n");
>>>> + return -EIO;
>>>> + }
>>>> + if (!acpi_buffer_out.pointer) {
>>>> + pr_err("Unexpected empty out buffer.\n");
>>>> + return -ENODATA;
>>>> + }
>>>
>>> I believe that printing error messages should be done by the callers
>>> of this method.
>>>
>>>> +
>>>> + *out = acpi_buffer_out.pointer;
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int __wmi_method_buffer_out(struct wmi_device *wdev,
>>>> uint32_t wmi_method_id, uint8_t *in,
>>>> + acpi_size in_len, uint8_t *out, acpi_size out_len)
>>>
>>> Please use size_t instead of acpi_size.
>>>
>>>> +{
>>>> + int ret;
>>>> + union acpi_object *acpi_object_out = NULL;
>>>
>>> union acpi_object *obj;
>>> int ret;
>> ack ack ack
>>>
>>>> +
>>>> + ret = __wmi_method_acpi_object_out(wdev, wmi_method_id, in,
>>>> in_len, &acpi_object_out);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + if (acpi_object_out->type != ACPI_TYPE_BUFFER) {
>>>> + pr_err("Unexpected out buffer type. Expected: %u Got:
>>>> %u\n", ACPI_TYPE_BUFFER,
>>>> + acpi_object_out->type);
>>>> + kfree(acpi_object_out);
>>>> + return -EIO;
>>>> + }
>>>> + if (acpi_object_out->buffer.length != out_len) {
>>>
>>> The Windows ACPI-WMI mappers accepts oversized buffers and ignores
>>> any additional data,
>>> so please change this code to also accept oversized buffers.
>> Only for input or also for output?
>
> Only forbuffers coming from the ACPI firmware.
ack
>
>>>
>>>> + pr_err("Unexpected out buffer length.\n");
>>>> + kfree(acpi_object_out);
>>>> + return -EIO;
>>>> + }
>>>> +
>>>> + memcpy(out, acpi_object_out->buffer.pointer, out_len);
>>>> + kfree(acpi_object_out);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +int tuxedo_nb04_wmi_8_b_in_80_b_out(struct wmi_device *wdev,
>>>> + enum tuxedo_nb04_wmi_8_b_in_80_b_out_methods
>>>> method,
>>>> + union tuxedo_nb04_wmi_8_b_in_80_b_out_input
>>>> *input,
>>>> + union tuxedo_nb04_wmi_8_b_in_80_b_out_output
>>>> *output)
>>>> +{
>>>> + return __wmi_method_buffer_out(wdev, method, input->raw, 8,
>>>> output->raw, 80);
>>>> +}
>>>> +
>>>> +int tuxedo_nb04_wmi_496_b_in_80_b_out(struct wmi_device *wdev,
>>>> + enum
>>>> tuxedo_nb04_wmi_496_b_in_80_b_out_methods method,
>>>> + union
>>>> tuxedo_nb04_wmi_496_b_in_80_b_out_input *input,
>>>> + union
>>>> tuxedo_nb04_wmi_496_b_in_80_b_out_output *output)
>>>> +{
>>>> + return __wmi_method_buffer_out(wdev, method, input->raw, 496,
>>>> output->raw, 80);
>>>> +}
>>>
>>> Those two functions seem useless to me, please use
>>> wmi_method_buffer_out() directly by passing
>>> a pointer to the underlying struct as data and the output of
>>> sizeof() as length.
>> They are thought of bringing some type safety into the mix so that
>> for any method id the input/output size is correct.
>
> I do not think that this brings any real benefits when it comes to
> type safety. Using predefined structs and sizeof()
> already takes care that the buffer size is correct, and choosing the
> correct method id already needs to be done by
> the driver itself.
ack
>
>>>
>>>> diff --git a/drivers/platform/x86/tuxedo/tuxedo_nb04_wmi_util.h
>>>> b/drivers/platform/x86/tuxedo/tuxedo_nb04_wmi_util.h
>>>> new file mode 100644
>>>> index 0000000000000..2765cbe9fcfef
>>>> --- /dev/null
>>>> +++ b/drivers/platform/x86/tuxedo/tuxedo_nb04_wmi_util.h
>>>> @@ -0,0 +1,112 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>> +/*
>>>> + * This code gives functions to avoid code duplication while
>>>> interacting with
>>>> + * the TUXEDO NB04 wmi interfaces.
>>>> + *
>>>> + * Copyright (C) 2024 Werner Sembach wse@tuxedocomputers.com
>>>> + */
>>>> +
>>>> +#ifndef TUXEDO_NB04_WMI_UTIL_H
>>>> +#define TUXEDO_NB04_WMI_UTIL_H
>>>> +
>>>> +#include <linux/wmi.h>
>>>> +
>>>> +#define WMI_AB_GET_DEVICE_STATUS_DEVICE_ID_TOUCHPAD 1
>>>> +#define WMI_AB_GET_DEVICE_STATUS_DEVICE_ID_KEYBOARD 2
>>>> +#define WMI_AB_GET_DEVICE_STATUS_DEVICE_ID_APP_PAGES 3
>>>> +
>>>> +#define WMI_AB_GET_DEVICE_STATUS_KBL_TYPE_NONE 0
>>>> +#define WMI_AB_GET_DEVICE_STATUS_KBL_TYPE_PER_KEY 1
>>>> +#define WMI_AB_GET_DEVICE_STATUS_KBL_TYPE_FOUR_ZONE 2
>>>> +#define WMI_AB_GET_DEVICE_STATUS_KBL_TYPE_WHITE_ONLY 3
>>>> +
>>>> +#define WMI_AB_GET_DEVICE_STATUS_KEYBOARD_LAYOUT_ANSII 0
>>>> +#define WMI_AB_GET_DEVICE_STATUS_KEYBOARD_LAYOUT_ISO 1
>>>> +
>>>> +#define WMI_AB_GET_DEVICE_STATUS_COLOR_ID_RED 1
>>>> +#define WMI_AB_GET_DEVICE_STATUS_COLOR_ID_GREEN 2
>>>> +#define WMI_AB_GET_DEVICE_STATUS_COLOR_ID_YELLOW 3
>>>> +#define WMI_AB_GET_DEVICE_STATUS_COLOR_ID_BLUE 4
>>>> +#define WMI_AB_GET_DEVICE_STATUS_COLOR_ID_PURPLE 5
>>>> +#define WMI_AB_GET_DEVICE_STATUS_COLOR_ID_INDIGO 6
>>>> +#define WMI_AB_GET_DEVICE_STATUS_COLOR_ID_WHITE 7
>>>> +
>>>> +#define WMI_AB_GET_DEVICE_STATUS_APP_PAGES_DASHBOARD BIT(0)
>>>> +#define WMI_AB_GET_DEVICE_STATUS_APP_PAGES_SYSTEMINFOS BIT(1)
>>>> +#define WMI_AB_GET_DEVICE_STATUS_APP_PAGES_KBL BIT(2)
>>>> +#define WMI_AB_GET_DEVICE_STATUS_APP_PAGES_HOTKEYS BIT(3)
>>>> +
>>>> +
>>>> +union tuxedo_nb04_wmi_8_b_in_80_b_out_input {
>>>> + uint8_t raw[8];
>>>> + struct __packed {
>>>> + uint8_t device_type;
>>>> + uint8_t reserved_0[7];
>>>> + } get_device_status_input;
>>>> +};
>>>> +
>>>> +union tuxedo_nb04_wmi_8_b_in_80_b_out_output {
>>>> + uint8_t raw[80];
>>>> + struct __packed {
>>>> + uint16_t return_status;
>>>> + uint8_t device_enabled;
>>>> + uint8_t kbl_type;
>>>> + uint8_t kbl_side_bar_supported;
>>>> + uint8_t keyboard_physical_layout;
>>>> + uint8_t app_pages;
>>>> + uint8_t per_key_kbl_default_color;
>>>> + uint8_t four_zone_kbl_default_color_1;
>>>> + uint8_t four_zone_kbl_default_color_2;
>>>> + uint8_t four_zone_kbl_default_color_3;
>>>> + uint8_t four_zone_kbl_default_color_4;
>>>> + uint8_t light_bar_kbl_default_color;
>>>> + uint8_t reserved_0[1];
>>>> + uint16_t dedicated_gpu_id;
>>>> + uint8_t reserved_1[64];
>>>> + } get_device_status_output;
>>>> +};
>>>> +
>>>> +enum tuxedo_nb04_wmi_8_b_in_80_b_out_methods {
>>>> + WMI_AB_GET_DEVICE_STATUS = 2,
>>>> +};
>>>> +
>>>> +
>>>> +#define WMI_AB_KBL_SET_MULTIPLE_KEYS_LIGHTING_SETTINGS_COUNT_MAX 120
>>>> +
>>>> +union tuxedo_nb04_wmi_496_b_in_80_b_out_input {
>>>> + uint8_t raw[496];
>>>> + struct __packed {
>>>> + uint8_t reserved_0[15];
>>>> + uint8_t lighting_setting_count;
>>>> + struct {
>>>> + uint8_t key_id;
>>>> + uint8_t red;
>>>> + uint8_t green;
>>>> + uint8_t blue;
>>>> + }
>>>> lighting_settings[WMI_AB_KBL_SET_MULTIPLE_KEYS_LIGHTING_SETTINGS_COUNT_MAX];
>>>> + } kbl_set_multiple_keys_input;
>>>> +};
>>>> +
>>>> +union tuxedo_nb04_wmi_496_b_in_80_b_out_output {
>>>> + uint8_t raw[80];
>>>> + struct __packed {
>>>> + uint8_t return_value;
>>>> + uint8_t reserved_0[79];
>>>> + } kbl_set_multiple_keys_output;
>>>> +};
>>>> +
>>>> +enum tuxedo_nb04_wmi_496_b_in_80_b_out_methods {
>>>> + WMI_AB_KBL_SET_MULTIPLE_KEYS = 6,
>>>> +};
>>>> +
>>>> +
>>>> +int tuxedo_nb04_wmi_8_b_in_80_b_out(struct wmi_device *wdev,
>>>> + enum tuxedo_nb04_wmi_8_b_in_80_b_out_methods
>>>> method,
>>>> + union tuxedo_nb04_wmi_8_b_in_80_b_out_input
>>>> *input,
>>>> + union tuxedo_nb04_wmi_8_b_in_80_b_out_output
>>>> *output);
>>>> +int tuxedo_nb04_wmi_496_b_in_80_b_out(struct wmi_device *wdev,
>>>> + enum
>>>> tuxedo_nb04_wmi_496_b_in_80_b_out_methods method,
>>>> + union
>>>> tuxedo_nb04_wmi_496_b_in_80_b_out_input *input,
>>>> + union
>>>> tuxedo_nb04_wmi_496_b_in_80_b_out_output *output);
>>>> +
>>>> +#endif
next prev parent reply other threads:[~2024-09-28 7:36 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-26 17:44 [PATCH 0/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 Werner Sembach
2024-09-26 17:44 ` [PATCH 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices Werner Sembach
2024-09-26 18:39 ` Armin Wolf
2024-09-27 6:59 ` Werner Sembach
2024-09-27 11:24 ` Werner Sembach
2024-09-27 17:18 ` Armin Wolf
2024-09-28 7:40 ` Werner Sembach
2024-09-27 17:15 ` Armin Wolf
2024-09-28 7:36 ` Werner Sembach [this message]
2024-09-27 8:59 ` kernel test robot
2024-09-27 9:20 ` kernel test robot
2024-09-27 12:18 ` kernel test robot
2024-09-27 21:01 ` Pavel Machek
2024-09-27 22:21 ` Armin Wolf
2024-09-28 7:27 ` Benjamin Tissoires
2024-09-28 8:23 ` Werner Sembach
2024-09-28 10:05 ` Benjamin Tissoires
2024-09-30 15:35 ` Werner Sembach
2024-09-30 16:15 ` Benjamin Tissoires
2024-09-30 16:35 ` Werner Sembach
2024-09-30 17:06 ` Benjamin Tissoires
2024-10-01 12:23 ` Werner Sembach
2024-10-01 12:28 ` Werner Sembach
2024-10-01 13:41 ` Benjamin Tissoires
2024-10-01 16:45 ` Armin Wolf
2024-10-01 19:32 ` Werner Sembach
2024-10-02 8:42 ` Benjamin Tissoires
2024-10-02 9:27 ` Armin Wolf
2024-10-03 16:01 ` Benjamin Tissoires
2024-10-01 19:18 ` Werner Sembach
2024-10-02 8:31 ` Benjamin Tissoires
2024-10-07 17:57 ` Werner Sembach
2024-10-08 9:53 ` Benjamin Tissoires
2024-10-08 10:45 ` Werner Sembach
2024-10-08 12:18 ` Benjamin Tissoires
2024-10-08 14:51 ` Werner Sembach
2024-10-08 15:21 ` Benjamin Tissoires
2024-10-09 9:55 ` Werner Sembach
2024-10-11 12:14 ` Armin Wolf
2024-10-11 15:26 ` Pavel Machek
2024-10-21 20:26 ` Armin Wolf
2024-10-22 7:58 ` Hans de Goede
2024-10-22 8:51 ` Benjamin Tissoires
2024-10-22 9:37 ` Pavel Machek
2024-10-22 15:02 ` Armin Wolf
2024-10-23 17:54 ` Werner Sembach
2024-10-22 9:47 ` Pavel Machek
2024-10-22 15:18 ` Armin Wolf
2024-10-22 19:15 ` Pavel Machek
2024-10-23 7:03 ` Armin Wolf
2024-10-23 17:14 ` Werner Sembach
2024-10-23 17:47 ` Pavel Machek
2024-10-23 16:38 ` Werner Sembach
2024-10-22 9:05 ` Benjamin Tissoires
2024-10-23 17:23 ` Werner Sembach
2024-10-01 21:03 ` Pavel Machek
2024-10-02 8:13 ` Benjamin Tissoires
2024-10-02 9:53 ` Pavel Machek
2024-10-02 10:21 ` Benjamin Tissoires
2024-10-03 10:59 ` Pavel Machek
2024-10-03 12:54 ` Benjamin Tissoires
2024-10-11 15:23 ` Pavel Machek
2024-09-28 8:09 ` Werner Sembach
2024-10-01 20:47 ` Pavel Machek
2024-09-28 7:55 ` Werner Sembach
2024-09-27 16:08 ` [PATCH 0/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 Benjamin Tissoires
2024-09-27 21:03 ` Pavel Machek
2024-09-28 7:31 ` Werner Sembach
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=cc7f3a74-5cb3-4e53-a941-2fc907c765f1@tuxedocomputers.com \
--to=wse@tuxedocomputers.com \
--cc=W_Armin@gmx.de \
--cc=bentiss@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jelle@vdwaa.nl \
--cc=jikos@kernel.org \
--cc=lee@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=onitake@gmail.com \
--cc=pavel@ucw.cz \
--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
all inboxes | Powered by JetHome®