All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Armin Wolf <W_Armin@gmx.de>
Cc: hdegoede@redhat.com, markgross@kernel.org, rafael@kernel.org,
	lenb@kernel.org, hmh@hmh.eng.br, matan@svgalib.org,
	corentin.chary@gmail.com, jeremy@system76.com,
	productdev@system76.com, mario.limonciello@amd.com,
	pobrn@protonmail.com, coproscefalo@gmail.com,
	platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] platform/x86: dell: Add new dell-wmi-ddv driver
Date: Wed, 28 Sep 2022 13:47:31 +0300	[thread overview]
Message-ID: <YzQmQw0hEwzXV/iz@smile.fi.intel.com> (raw)
In-Reply-To: <20220927204521.601887-3-W_Armin@gmx.de>

On Tue, Sep 27, 2022 at 10:45:21PM +0200, Armin Wolf wrote:
> The dell-wmi-ddv driver adds support for reading
> the current temperature and ePPID of ACPI batteries
> on supported Dell machines.
> 
> Since the WMI interface used by this driver does not
> do any input validation and thus cannot be used for probing,
> the driver depends on the ACPI battery extension machanism
> to discover batteries.
> 
> The driver also supports a debugfs interface for retrieving
> buffers containing fan and thermal sensor information.
> Since the meaing of the content of those buffers is currently
> unknown, the interface is meant for reverse-engineering and
> will likely be replaced with an hwmon interface once the
> meaning has been understood.
> 
> The driver was tested on a Dell Inspiron 3505.

...

> +config DELL_WMI_DDV
> +	tristate "Dell WMI sensors Support"

> +	default m

Why? (Imagine I have Dell, but old machine)

(And yes, I see that other Kconfig options are using it, but we shall avoid
 cargo cult and each default choice like this has to be explained at least.)

...

> + * dell-wmi-ddv.c -- Linux driver for WMI sensor information on Dell notebooks.

Please, remove file name from the file. This will be an additional burden in
the future in case it will be renamed.

...

> +#include <acpi/battery.h>

Is it required to be the first? Otherwise it seems ACPI specific to me and the
general rule is to put inclusions from generic towards custom. I.o.w. can you
move it after linux/wmi.h with a blank line in between?

> +#include <linux/acpi.h>
> +#include <linux/debugfs.h>
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/kstrtox.h>
> +#include <linux/math.h>
> +#include <linux/module.h>
> +#include <linux/limits.h>
> +#include <linux/power_supply.h>
> +#include <linux/seq_file.h>
> +#include <linux/sysfs.h>
> +#include <linux/wmi.h>

...

> +struct dell_wmi_ddv_data {
> +	struct acpi_battery_hook hook;
> +	struct device_attribute temp_attr, eppid_attr;

It's hard to read and easy to miss that the data type has two members here.
Please, put one member per one line.

> +	struct wmi_device *wdev;
> +};

...

> +	if (obj->type != type) {
> +		kfree(obj);
> +		return -EIO;

EINVAL?

> +	}

...

> +	kfree(obj);

I'm wondering what is the best to use in the drivers:
 1) kfree()
 2) acpi_os_free()
 3) ACPI_FREE()

?

...

> +static int dell_wmi_ddv_battery_index(struct acpi_device *acpi_dev, u32 *index)
> +{

> +	const char *uid_str = acpi_device_uid(acpi_dev);
> +
> +	if (!uid_str)
> +		return -ENODEV;

It will be better for maintaining to have

	const char *uid_str...;

	uid_str = ...
	if (!uid_str)
		...

> +	return kstrtou32(uid_str, 10, index);
> +}

...

> +	/* Return 0 instead of error to avoid being unloaded */
> +	ret = dell_wmi_ddv_battery_index(to_acpi_device(battery->dev.parent), &index);
> +	if (ret < 0)
> +		return 0;

How index is used?

...

> +	ret = device_create_file(&battery->dev, &data->temp_attr);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = device_create_file(&battery->dev, &data->eppid_attr);
> +	if (ret < 0) {
> +		device_remove_file(&battery->dev, &data->temp_attr);
> +
> +		return ret;
> +	}

Why dev_groups member can't be utilized?

...

> +static void dell_wmi_ddv_debugfs_init(struct wmi_device *wdev)

Strictly speaking this should return int (see below).

> +{
> +	struct dentry *entry;
> +	char name[64];
> +
> +	scnprintf(name, ARRAY_SIZE(name), "%s-%s", DRIVER_NAME, dev_name(&wdev->dev));
> +	entry = debugfs_create_dir(name, NULL);
> +
> +	debugfs_create_devm_seqfile(&wdev->dev, "fan_sensor_information", entry,
> +				    dell_wmi_ddv_fan_read);
> +	debugfs_create_devm_seqfile(&wdev->dev, "thermal_sensor_information", entry,
> +				    dell_wmi_ddv_temp_read);
> +
> +	devm_add_action_or_reset(&wdev->dev, dell_wmi_ddv_debugfs_remove, entry);

return devm...

This is not related to debugfs and there is no rule to avoid checking error
codes from devm_add_action_or_reset().

> +}

...

> +static struct wmi_driver dell_wmi_ddv_driver = {
> +	.driver = {
> +		.name = DRIVER_NAME,

I would use explicit literal since this is a (semi-) ABI, and having it as
a define feels not fully right.

> +	},
> +	.id_table = dell_wmi_ddv_id_table,
> +	.probe = dell_wmi_ddv_probe,
> +};

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2022-09-28 10:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-27 20:45 [PATCH v2 0/2] platform/x86: dell: Add new dell-wmi-ddv driver Armin Wolf
2022-09-27 20:45 ` [PATCH v2 1/2] ACPI: battery: Pass battery hook pointer to hook callbacks Armin Wolf
2022-10-24 13:19   ` Rafael J. Wysocki
2022-10-24 13:47   ` Hans de Goede
2022-09-27 20:45 ` [PATCH v2 2/2] platform/x86: dell: Add new dell-wmi-ddv driver Armin Wolf
2022-09-28 10:47   ` Andy Shevchenko [this message]
2022-09-28 11:33     ` Hans de Goede
2022-09-28 14:16       ` Andy Shevchenko
2022-09-28 20:57     ` Armin Wolf
2022-09-29  9:50       ` Andy Shevchenko
2022-09-29 13:12         ` Hans de Goede
2022-10-21  9:34           ` Armin Wolf
2022-10-21  9:58             ` Hans de Goede
2022-09-29  9:51       ` Andy Shevchenko
2022-09-28  9:52 ` [PATCH v2 0/2] " Hans de Goede
2022-09-28 10:48   ` Andy Shevchenko
2022-09-28 11:37     ` Hans de Goede

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=YzQmQw0hEwzXV/iz@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=W_Armin@gmx.de \
    --cc=coproscefalo@gmail.com \
    --cc=corentin.chary@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=hmh@hmh.eng.br \
    --cc=jeremy@system76.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=markgross@kernel.org \
    --cc=matan@svgalib.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=pobrn@protonmail.com \
    --cc=productdev@system76.com \
    --cc=rafael@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.