From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Kurt Borja <kuurtb@gmail.com>
Cc: platform-driver-x86@vger.kernel.org,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Armin Wolf" <W_Armin@gmx.de>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Hans de Goede" <hdegoede@redhat.com>,
Dell.Client.Kernel@dell.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 11/14] platform/x86: Split the alienware-wmi driver
Date: Tue, 11 Feb 2025 18:56:07 +0200 [thread overview]
Message-ID: <Z6uBJ9AC5XgZTlJG@black.fi.intel.com> (raw)
In-Reply-To: <20250207154610.13675-12-kuurtb@gmail.com>
On Fri, Feb 07, 2025 at 10:46:07AM -0500, Kurt Borja wrote:
> Split alienware-wmi WMI drivers into different files. This is done
> seamlessly by copying and pasting, however some blocks are reordered.
...
> obj-$(CONFIG_ALIENWARE_WMI) += alienware-wmi.o
> alienware-wmi-objs := alienware-wmi-base.o
> +alienware-wmi-y += alienware-wmi-legacy.o
> +alienware-wmi-y += alienware-wmi-wmax.o
Oh my... it's even inconsistent!
...
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/wmi.h>
Too little headers are being included. At very quick glance a dozen
or so is missing...
> +#include "alienware-wmi.h"
...
> +static struct attribute *hdmi_attrs[] = {
> + &dev_attr_cable.attr,
> + &dev_attr_source.attr,
> + NULL,
No comma in the terminator entry.
> +};
...
> +static struct attribute *amplifier_attrs[] = {
> + &dev_attr_status.attr,
> + NULL,
> +};
Ditto.
...
> +{
> + struct alienfx_platdata *pdata = dev_get_platdata(dev);
> + struct wmax_basic_args in_args = {
> + .arg = 0,
> + };
> + u32 out_data;
> + int ret;
> +
> + ret = alienware_wmi_command(pdata->wdev, WMAX_METHOD_DEEP_SLEEP_STATUS,
> + &in_args, sizeof(in_args), &out_data);
> + if (!ret) {
> + if (out_data == 0)
> + return sysfs_emit(buf, "[disabled] s5 s5_s4\n");
> + else if (out_data == 1)
> + return sysfs_emit(buf, "disabled [s5] s5_s4\n");
> + else if (out_data == 2)
> + return sysfs_emit(buf, "disabled s5 [s5_s4]\n");
The whole code inherited same issues like redundant 'else'. Please, refactor.
> + }
> +
> + pr_err("alienware-wmi: unknown deep sleep status: %d\n", ret);
> + return sysfs_emit(buf, "disabled s5 s5_s4 [unknown]\n");
> +}
...
> +static ssize_t deepsleep_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct alienfx_platdata *pdata = dev_get_platdata(dev);
> + struct wmax_basic_args args;
> + int ret;
> +
> + if (strcmp(buf, "disabled\n") == 0)
> + args.arg = 0;
> + else if (strcmp(buf, "s5\n") == 0)
> + args.arg = 1;
> + else
> + args.arg = 2;
sysfs_match_string()
> + pr_debug("alienware-wmi: setting deep sleep to %d : %s", args.arg, buf);
> +
> + ret = alienware_wmi_command(pdata->wdev, WMAX_METHOD_DEEP_SLEEP_CONTROL,
> + &args, sizeof(args), NULL);
> + if (!ret)
> + pr_err("alienware-wmi: deep sleep control failed: results: %u\n", ret);
> +
> + return count;
> +}
> +
Redundant blank line.
> +static DEVICE_ATTR_RW(deepsleep);
...
> +static struct attribute *deepsleep_attrs[] = {
> + &dev_attr_deepsleep.attr,
> + NULL,
No comma.
> +};
...
> + if ((code & WMAX_THERMAL_TABLE_MASK) == WMAX_THERMAL_TABLE_USTT &&
> + (code & WMAX_THERMAL_MODE_MASK) <= THERMAL_MODE_USTT_LOW_POWER)
> + return true;
> +
> + return false;
return ...
but if you wish, this one is okay.
...
> +static int thermal_profile_probe(void *drvdata, unsigned long *choices)
> +{
> + enum platform_profile_option profile;
> + struct awcc_priv *priv = drvdata;
> + enum wmax_thermal_mode mode;
> + u8 sys_desc[4];
> + u32 first_mode;
> + u32 out_data;
> + int ret;
> +
> + ret = wmax_thermal_information(priv->wdev, WMAX_OPERATION_SYS_DESCRIPTION,
> + 0, (u32 *) &sys_desc);
How do you guarantee an alignment? Yes, it might be good for the specific
hardware, but in general this is broken code.
> + if (ret < 0)
> + return ret;
> +
> + first_mode = sys_desc[0] + sys_desc[1];
> + for (u32 i = 0; i < sys_desc[3]; i++) {
Why u32? unsigned int looks more natural here.
> + ret = wmax_thermal_information(priv->wdev, WMAX_OPERATION_LIST_IDS,
> + i + first_mode, &out_data);
> +
> + if (ret == -EIO)
> + return ret;
> +
> + if (ret == -EBADRQC)
> + break;
> +
> + if (!is_wmax_thermal_code(out_data))
> + continue;
> +
> + mode = out_data & WMAX_THERMAL_MODE_MASK;
> + profile = wmax_mode_to_platform_profile[mode];
> + priv->supported_thermal_profiles[profile] = out_data;
> + set_bit(profile, choices);
Do you need it to be atomic?
> + }
> +
> + if (bitmap_empty(choices, PLATFORM_PROFILE_LAST))
> + return -ENODEV;
> +
> + if (awcc->gmode) {
> + priv->supported_thermal_profiles[PLATFORM_PROFILE_PERFORMANCE] =
> + WMAX_THERMAL_MODE_GMODE;
> +
> + set_bit(PLATFORM_PROFILE_PERFORMANCE, choices);
> + }
> +
> + return 0;
> +}
...
> +static const struct wmi_device_id alienware_wmax_device_id_table[] = {
> + { WMAX_CONTROL_GUID, NULL },
> + { },
No comma.
> +};
...
> +int __init alienware_wmax_wmi_init(void)
> +{
> + const struct dmi_system_id *id;
> +
> + id = dmi_first_match(awcc_dmi_table);
> + if (id)
> + awcc = id->driver_data;
> +
> + if (force_platform_profile) {
> + if (!awcc)
> + awcc = &empty_quirks;
> +
> + awcc->pprof = true;
> + }
> +
> + if (force_gmode) {
> + if (awcc)
> + awcc->gmode = true;
> + else
> + pr_warn("force_gmode requires platform profile support\n");
> + }
> +
> + return wmi_driver_register(&alienware_wmax_wmi_driver);
> +}
> +
> +void __exit alienware_wmax_wmi_exit(void)
> +{
> + wmi_driver_unregister(&alienware_wmax_wmi_driver);
> +}
Why not moving these boilerplate to ->probe() and use module_wmi_driver()?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-02-11 16:56 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 15:45 [PATCH v10 00/14] platform/x86: alienware-wmi driver rework Kurt Borja
2025-02-07 15:45 ` [PATCH v10 01/14] platform/x86: alienware-wmi: Add a state container for LED control feature Kurt Borja
2025-02-07 15:45 ` [PATCH v10 02/14] platform/x86: alienware-wmi: Add WMI Drivers Kurt Borja
2025-02-11 16:30 ` Andy Shevchenko
2025-02-11 17:46 ` Kurt Borja
2025-02-11 18:51 ` Andy Shevchenko
2025-02-07 15:45 ` [PATCH v10 03/14] platform/x86: alienware-wmi: Add a state container for thermal control methods Kurt Borja
2025-02-07 15:46 ` [PATCH v10 04/14] platform/x86: alienware-wmi: Refactor LED " Kurt Borja
2025-02-11 16:33 ` Andy Shevchenko
2025-02-11 17:47 ` Kurt Borja
2025-02-07 15:46 ` [PATCH v10 05/14] platform/x86: alienware-wmi: Refactor hdmi, amplifier, deepslp methods Kurt Borja
2025-02-11 16:37 ` Andy Shevchenko
2025-02-11 17:51 ` Kurt Borja
2025-02-11 18:55 ` Andy Shevchenko
2025-02-07 15:46 ` [PATCH v10 06/14] platform/x86: alienware-wmi: Refactor thermal control methods Kurt Borja
2025-02-07 15:46 ` [PATCH v10 07/14] platform/x86: alienware-wmi: Split DMI table Kurt Borja
2025-02-11 16:39 ` Andy Shevchenko
2025-02-11 17:53 ` Kurt Borja
2025-02-07 15:46 ` [PATCH v10 08/14] MAINTAINERS: Update ALIENWARE WMI DRIVER entry Kurt Borja
2025-02-07 15:46 ` [PATCH v10 09/14] platform/x86: Rename alienware-wmi.c Kurt Borja
2025-02-11 16:41 ` Andy Shevchenko
2025-02-11 17:31 ` Kurt Borja
2025-02-11 18:50 ` Andy Shevchenko
2025-02-07 15:46 ` [PATCH v10 10/14] platform/x86: Add alienware-wmi.h Kurt Borja
2025-02-11 16:45 ` Andy Shevchenko
2025-02-11 16:51 ` Ilpo Järvinen
2025-02-11 17:19 ` Andy Shevchenko
2025-02-11 17:53 ` Kurt Borja
2025-02-07 15:46 ` [PATCH v10 11/14] platform/x86: Split the alienware-wmi driver Kurt Borja
2025-02-11 16:56 ` Andy Shevchenko [this message]
2025-02-11 17:59 ` Kurt Borja
2025-02-11 19:04 ` Andy Shevchenko
2025-02-14 22:21 ` Kurt Borja
2025-02-16 20:35 ` Andy Shevchenko
2025-02-07 15:46 ` [PATCH v10 12/14] platform/x86: dell: Modify Makefile alignment Kurt Borja
2025-02-11 16:56 ` Andy Shevchenko
2025-02-07 15:46 ` [PATCH v10 13/14] platform/x86: Update alienware-wmi config entries Kurt Borja
2025-02-07 15:46 ` [PATCH v10 14/14] platform/x86: alienware-wmi: Update header and module information Kurt Borja
2025-02-10 11:53 ` [PATCH v10 00/14] platform/x86: alienware-wmi driver rework Ilpo Järvinen
2025-02-10 13:48 ` Kurt Borja
2025-02-11 16:58 ` Andy Shevchenko
2025-02-11 18:09 ` Kurt Borja
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=Z6uBJ9AC5XgZTlJG@black.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=Dell.Client.Kernel@dell.com \
--cc=W_Armin@gmx.de \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kuurtb@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--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