lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <da9fe05a-a12d-4a2d-a81a-1195d65b1d51@gmail.com>
Date:   Tue, 5 Dec 2023 15:22:49 +0100
From:   Aleksa Savic <savicaleksa83@...il.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     savicaleksa83@...il.com, linux-hwmon@...r.kernel.org,
        Jean Delvare <jdelvare@...e.com>,
        Jonathan Corbet <corbet@....net>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] hwmon: Add driver for Gigabyte AORUS Waterforce AIO
 coolers

On 2023-12-03 18:36:35 GMT+01:00, Guenter Roeck wrote:
> On Sun, Dec 03, 2023 at 01:06:48PM +0100, Aleksa Savic wrote:
>> This driver exposes hardware sensors of the Gigabyte AORUS Waterforce
>> all-in-one CPU liquid coolers, which communicate through a proprietary
>> USB HID protocol. Report offsets were initially discovered in [1] and
>> confirmed by me on a Waterforce X240 by observing the sent reports from
>> the official software.
>>
>> Available sensors are pump and fan speed in RPM, as well as coolant
>> temperature. Also available through debugfs is the firmware version.
>>
>> Attaching a fan is optional and allows it to be controlled from the
>> device. If it's not connected, the fan-related sensors will report
>> zeroes.
>>
>> The addressable RGB LEDs and LCD screen are not supported in this
>> driver and should be controlled through userspace tools.
>>
>> [1]: https://github.com/liquidctl/liquidctl/issues/167
>>
>> Signed-off-by: Aleksa Savic <savicaleksa83@...il.com>
>> ---
>> Changes in v2 (fix issues reported by kernel bot):
>> - Add driver doc to hwmon doc index
>> - Initialize ret value in waterforce_get_status() to 0
>> ---
>>  Documentation/hwmon/gigabyte_waterforce.rst |  47 +++
>>  Documentation/hwmon/index.rst               |   1 +
>>  MAINTAINERS                                 |   7 +
>>  drivers/hwmon/Kconfig                       |  10 +
>>  drivers/hwmon/Makefile                      |   1 +
>>  drivers/hwmon/gigabyte_waterforce.c         | 439 ++++++++++++++++++++
>>  6 files changed, 505 insertions(+)
>>  create mode 100644 Documentation/hwmon/gigabyte_waterforce.rst
>>  create mode 100644 drivers/hwmon/gigabyte_waterforce.c
>>
>> diff --git a/Documentation/hwmon/gigabyte_waterforce.rst b/Documentation/hwmon/gigabyte_waterforce.rst
>> new file mode 100644
>> index 000000000000..d47f3e8516ee
>> --- /dev/null
>> +++ b/Documentation/hwmon/gigabyte_waterforce.rst
>> @@ -0,0 +1,47 @@
>> +.. SPDX-License-Identifier: GPL-2.0-or-later
>> +
>> +Kernel driver gigabyte_waterforce
>> +=================================
>> +
>> +Supported devices:
>> +
>> +* Gigabyte AORUS WATERFORCE X240
>> +* Gigabyte AORUS WATERFORCE X280
>> +* Gigabyte AORUS WATERFORCE X360
>> +
>> +Author: Aleksa Savic
>> +
>> +Description
>> +-----------
>> +
>> +This driver enables hardware monitoring support for the listed Gigabyte Waterforce
>> +all-in-one CPU liquid coolers. Available sensors are pump and fan speed in RPM, as
>> +well as coolant temperature. Also available through debugfs is the firmware version.
>> +
>> +Attaching a fan is optional and allows it to be controlled from the device. If
>> +it's not connected, the fan-related sensors will report zeroes.
>> +
>> +The addressable RGB LEDs and LCD screen are not supported in this driver and should
>> +be controlled through userspace tools.
>> +
>> +Usage notes
>> +-----------
>> +
>> +As these are USB HIDs, the driver can be loaded automatically by the kernel and
>> +supports hot swapping.
>> +
>> +Sysfs entries
>> +-------------
>> +
>> +=========== =============================================
>> +fan1_input  Fan speed (in rpm)
>> +fan2_input  Pump speed (in rpm)
>> +temp1_input Coolant temperature (in millidegrees Celsius)
>> +=========== =============================================
>> +
>> +Debugfs entries
>> +---------------
>> +
>> +================ =======================
>> +firmware_version Device firmware version
>> +================ =======================
>> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
>> index 095c36f5e8a1..36101e9e38e9 100644
>> --- a/Documentation/hwmon/index.rst
>> +++ b/Documentation/hwmon/index.rst
>> @@ -73,6 +73,7 @@ Hardware Monitoring Kernel Drivers
>>     ftsteutates
>>     g760a
>>     g762
>> +   gigabyte_waterforce
>>     gsc-hwmon
>>     gl518sm
>>     gxp-fan-ctrl
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 97f51d5ec1cf..b1a69c5042b8 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8960,6 +8960,13 @@ F:	Documentation/filesystems/gfs2*
>>  F:	fs/gfs2/
>>  F:	include/uapi/linux/gfs2_ondisk.h
>>  
>> +GIGABYTE WATERFORCE SENSOR DRIVER
>> +M:	Aleksa Savic <savicaleksa83@...il.com>
>> +L:	linux-hwmon@...r.kernel.org
>> +S:	Maintained
>> +F:	Documentation/hwmon/gigabyte_waterforce.rst
>> +F:	drivers/hwmon/gigabyte_waterforce.c
>> +
>>  GIGABYTE WMI DRIVER
>>  M:	Thomas Weißschuh <thomas@...ssschuh.net>
>>  L:	platform-driver-x86@...r.kernel.org
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 76cb05db1dcf..a608264da87d 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -664,6 +664,16 @@ config SENSORS_FTSTEUTATES
>>  	  This driver can also be built as a module. If so, the module
>>  	  will be called ftsteutates.
>>  
>> +config SENSORS_GIGABYTE_WATERFORCE
>> +	tristate "Gigabyte Waterforce X240/X280/X360 AIO CPU coolers"
>> +	depends on USB_HID
>> +	help
>> +	  If you say yes here you get support for hardware monitoring for the
>> +	  Gigabyte Waterforce X240/X280/X360 all-in-one CPU liquid coolers.
>> +
>> +	  This driver can also be built as a module. If so, the module
>> +	  will be called gigabyte_waterforce.
>> +
>>  config SENSORS_GL518SM
>>  	tristate "Genesys Logic GL518SM"
>>  	depends on I2C
>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>> index e84bd9685b5c..47be39af5c03 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -80,6 +80,7 @@ obj-$(CONFIG_SENSORS_FSCHMD)	+= fschmd.o
>>  obj-$(CONFIG_SENSORS_FTSTEUTATES) += ftsteutates.o
>>  obj-$(CONFIG_SENSORS_G760A)	+= g760a.o
>>  obj-$(CONFIG_SENSORS_G762)	+= g762.o
>> +obj-$(CONFIG_SENSORS_GIGABYTE_WATERFORCE) += gigabyte_waterforce.o
>>  obj-$(CONFIG_SENSORS_GL518SM)	+= gl518sm.o
>>  obj-$(CONFIG_SENSORS_GL520SM)	+= gl520sm.o
>>  obj-$(CONFIG_SENSORS_GSC)	+= gsc-hwmon.o
>> diff --git a/drivers/hwmon/gigabyte_waterforce.c b/drivers/hwmon/gigabyte_waterforce.c
>> new file mode 100644
>> index 000000000000..5c1084ad340a
>> --- /dev/null
>> +++ b/drivers/hwmon/gigabyte_waterforce.c
>> @@ -0,0 +1,439 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * hwmon driver for Gigabyte AORUS Waterforce AIO CPU coolers: X240, X280 and X360.
>> + *
>> + * Copyright 2023 Aleksa Savic <savicaleksa83@...il.com>
>> + */
>> +
>> +#include <linux/debugfs.h>
>> +#include <linux/hid.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/module.h>
>> +#include <linux/spinlock.h>
>> +#include <asm/unaligned.h>
>> +
>> +#define DRIVER_NAME	"gigabyte_waterforce"
>> +
>> +#define USB_VENDOR_ID_GIGABYTE		0x1044
>> +#define USB_PRODUCT_ID_WATERFORCE	0x7a4d	/* Gigabyte AORUS WATERFORCE X240, X280 and X360 */
>> +
>> +#define STATUS_VALIDITY		(2 * 1000)	/* ms */
>> +#define MAX_REPORT_LENGTH	6144
>> +
>> +#define WATERFORCE_TEMP_SENSOR	0xD
>> +#define WATERFORCE_FAN_SPEED	0x02
>> +#define WATERFORCE_PUMP_SPEED	0x05
>> +#define WATERFORCE_FAN_DUTY	0x08
>> +#define WATERFORCE_PUMP_DUTY	0x09
>> +
>> +/* Control commands, inner offsets and lengths */
>> +static const u8 get_status_cmd[] = { 0x99, 0xDA };
>> +
>> +#define FIRMWARE_VER_START_OFFSET_1	2
>> +#define FIRMWARE_VER_START_OFFSET_2	3
>> +static const u8 get_firmware_ver_cmd[] = { 0x99, 0xD6 };
>> +
>> +/* Command lengths */
>> +#define GET_STATUS_CMD_LENGTH		2
>> +#define GET_FIRMWARE_VER_CMD_LENGTH	2
>> +
>> +static const char *const waterforce_temp_label[] = {
>> +	"Coolant temp"
>> +};
>> +
>> +static const char *const waterforce_speed_label[] = {
>> +	"Fan speed",
>> +	"Pump speed"
>> +};
>> +
>> +struct waterforce_data {
>> +	struct hid_device *hdev;
>> +	struct device *hwmon_dev;
>> +	struct dentry *debugfs;
>> +	/* For locking access to buffer */
>> +	struct mutex buffer_lock;
>> +	/* For queueing multiple readers */
>> +	struct mutex status_report_request_mutex;
>> +	/* For reinitializing the completion below */
>> +	spinlock_t status_report_request_lock;
>> +	struct completion status_report_received;
>> +	struct completion fw_version_processed;
>> +
>> +	/* Sensor data */
>> +	s32 temp_input[1];
>> +	u16 speed_input[2];	/* Fan and pump speed in RPM */
>> +	u8 duty_input[2];	/* Fan and pump duty in 0-100% */
>> +
>> +	u8 *buffer;
>> +	int firmware_version;
>> +	unsigned long updated;	/* jiffies */
>> +};
>> +
>> +static umode_t waterforce_is_visible(const void *data,
>> +				     enum hwmon_sensor_types type, u32 attr, int channel)
>> +{
>> +	switch (type) {
>> +	case hwmon_temp:
>> +		switch (attr) {
>> +		case hwmon_temp_label:
>> +		case hwmon_temp_input:
>> +			return 0444;
>> +		default:
>> +			break;
>> +		}
>> +		break;
>> +	case hwmon_fan:
>> +		switch (attr) {
>> +		case hwmon_fan_label:
>> +		case hwmon_fan_input:
>> +			return 0444;
>> +		default:
>> +			break;
>> +		}
>> +		break;
>> +	case hwmon_pwm:
>> +		switch (attr) {
>> +		case hwmon_pwm_input:
>> +			return 0444;
>> +		default:
>> +			break;
>> +		}
>> +		break;
>> +	default:
>> +		break;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +/* Writes the command to the device with the rest of the report filled with zeroes */
>> +static int waterforce_write_expanded(struct waterforce_data *priv, const u8 *cmd, int cmd_length)
>> +{
>> +	int ret;
>> +
>> +	mutex_lock(&priv->buffer_lock);
>> +
>> +	memset(priv->buffer, 0x00, MAX_REPORT_LENGTH);
>> +	memcpy(priv->buffer, cmd, cmd_length);
>> +	ret = hid_hw_output_report(priv->hdev, priv->buffer, MAX_REPORT_LENGTH);
>> +
>> +	mutex_unlock(&priv->buffer_lock);
>> +	return ret;
>> +}
>> +
>> +static int waterforce_get_status(struct waterforce_data *priv)
>> +{
>> +	int ret = 0;
>> +
>> +	if (!mutex_lock_interruptible(&priv->status_report_request_mutex)) {
>> +		if (!time_after(jiffies, priv->updated + msecs_to_jiffies(STATUS_VALIDITY))) {
>> +			/* Data is up to date */
>> +			goto unlock_and_return;
>> +		}
> 
> What is the point of this check ? The calling code already checks it.
> Checking it twice, once inside and once outside the lock, seems
> excessive.
> 

If there are multiple readers here, only the first one should request the status,
so when others enter the mutex they can exit early if the data is there.

>> +
>> +		/*
>> +		 * Disable raw event parsing for a moment to safely reinitialize the
>> +		 * completion. Reinit is done because hidraw could have triggered
>> +		 * the raw event parsing and marked the priv->status_report_received
>> +		 * completion as done.
>> +		 */
>> +		spin_lock_bh(&priv->status_report_request_lock);
>> +		reinit_completion(&priv->status_report_received);
>> +		spin_unlock_bh(&priv->status_report_request_lock);
>> +
>> +		/* Send command for getting status */
>> +		ret = waterforce_write_expanded(priv, get_status_cmd, GET_STATUS_CMD_LENGTH);
>> +		if (ret < 0)
>> +			return ret;
>> +
>> +		if (wait_for_completion_interruptible_timeout
>> +		    (&priv->status_report_received, msecs_to_jiffies(STATUS_VALIDITY)) <= 0)
>> +			ret = -ENODATA;
> 
> -ETIMEDOUT if timed out, or error code if one was reported.

Fixed this and other error code returns in v3.

> 
>> +unlock_and_return:
>> +		mutex_unlock(&priv->status_report_request_mutex);
>> +		if (ret < 0)
>> +			return ret;
>> +	} else {
>> +		return -ENODATA;
>> +	}
> 
> This should be something like
> 
> 	rc = mutex_lock_interruptible(&priv->status_report_request_mutex);
> 	if (rc)
> 		return rc;
> 
> The returned error code should not be overwritten. If you want to make the mutex
> interruptible, report the interrupt event to the caller.
> 

Fixed in v3.

>> +
>> +	return 0;
>> +}
>> +
>> +static int waterforce_read(struct device *dev, enum hwmon_sensor_types type,
>> +			   u32 attr, int channel, long *val)
>> +{
>> +	int ret;
>> +	struct waterforce_data *priv = dev_get_drvdata(dev);
> 
> I don't enfore it, but declaring variables in reverse christmas tree order
> (longer variables first) does look nicer.

I agree, reformatted in v3.

>> +
>> +	if (time_after(jiffies, priv->updated + msecs_to_jiffies(STATUS_VALIDITY))) {
>> +		/* Request status on demand */
>> +		ret = waterforce_get_status(priv);
>> +		if (ret < 0)
>> +			return -ENODATA;
> 
> Again, please do not overwrite error codes. Here you are overwriting it twice,
> which is really not appropriate.
> 
>> +	}
>> +
>> +	switch (type) {
>> +	case hwmon_temp:
>> +		*val = priv->temp_input[channel];
>> +		break;
>> +	case hwmon_fan:
>> +		*val = priv->speed_input[channel];
>> +		break;
>> +	case hwmon_pwm:
>> +		switch (attr) {
>> +		case hwmon_pwm_input:
>> +			*val = DIV_ROUND_CLOSEST(priv->duty_input[channel] * 255, 100);
>> +			break;
>> +		default:
>> +			break;
>> +		}
>> +		break;
>> +	default:
>> +		return -EOPNOTSUPP;	/* unreachable */
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static int waterforce_read_string(struct device *dev, enum hwmon_sensor_types type,
>> +				  u32 attr, int channel, const char **str)
>> +{
>> +	switch (type) {
>> +	case hwmon_temp:
>> +		*str = waterforce_temp_label[channel];
>> +		break;
>> +	case hwmon_fan:
>> +		*str = waterforce_speed_label[channel];
>> +		break;
>> +	default:
>> +		return -EOPNOTSUPP;	/* unreachable */
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static int waterforce_get_fw_ver(struct hid_device *hdev)
>> +{
>> +	int ret;
>> +	struct waterforce_data *priv = hid_get_drvdata(hdev);
>> +
>> +	ret = waterforce_write_expanded(priv, get_firmware_ver_cmd, GET_FIRMWARE_VER_CMD_LENGTH);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (wait_for_completion_interruptible_timeout
>> +	    (&priv->fw_version_processed, msecs_to_jiffies(STATUS_VALIDITY)) <= 0)
>> +		return -ENODATA;
> 
> Another overwritten error code.
> 
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct hwmon_ops waterforce_hwmon_ops = {
>> +	.is_visible = waterforce_is_visible,
>> +	.read = waterforce_read,
>> +	.read_string = waterforce_read_string
>> +};
>> +
>> +static const struct hwmon_channel_info *waterforce_info[] = {
>> +	HWMON_CHANNEL_INFO(temp,
>> +			   HWMON_T_INPUT | HWMON_T_LABEL),
>> +	HWMON_CHANNEL_INFO(fan,
>> +			   HWMON_F_INPUT | HWMON_F_LABEL,
>> +			   HWMON_F_INPUT | HWMON_F_LABEL),
>> +	HWMON_CHANNEL_INFO(pwm,
>> +			   HWMON_PWM_INPUT,
>> +			   HWMON_PWM_INPUT),
>> +	NULL
>> +};
>> +
>> +static const struct hwmon_chip_info waterforce_chip_info = {
>> +	.ops = &waterforce_hwmon_ops,
>> +	.info = waterforce_info,
>> +};
>> +
>> +static int waterforce_raw_event(struct hid_device *hdev, struct hid_report *report, u8 *data,
>> +				int size)
>> +{
>> +	struct waterforce_data *priv = hid_get_drvdata(hdev);
>> +
>> +	if (data[0] == get_firmware_ver_cmd[0] && data[1] == get_firmware_ver_cmd[1]) {
>> +		/* Received a firmware version report */
>> +		priv->firmware_version =
>> +		    data[FIRMWARE_VER_START_OFFSET_1] * 10 + data[FIRMWARE_VER_START_OFFSET_2];
>> +
>> +		if (!completion_done(&priv->fw_version_processed))
>> +			complete_all(&priv->fw_version_processed);
>> +		return 0;
>> +	}
>> +
>> +	if (data[0] != get_status_cmd[0] || data[1] != get_status_cmd[1])
>> +		return 0;
>> +
>> +	priv->temp_input[0] = data[WATERFORCE_TEMP_SENSOR] * 1000;
>> +	priv->speed_input[0] = get_unaligned_le16(data + WATERFORCE_FAN_SPEED);
>> +	priv->speed_input[1] = get_unaligned_le16(data + WATERFORCE_PUMP_SPEED);
>> +	priv->duty_input[0] = data[WATERFORCE_FAN_DUTY];
>> +	priv->duty_input[1] = data[WATERFORCE_PUMP_DUTY];
>> +
>> +	if (!completion_done(&priv->status_report_received))
>> +		complete_all(&priv->status_report_received);
>> +
>> +	priv->updated = jiffies;
>> +
>> +	return 0;
>> +}
>> +
>> +#ifdef CONFIG_DEBUG_FS
>> +
> 
> Those ifdefs are unnecessary.
> 

Fixed in v3. I'll look into removing the ifdef from aquacomputer_d5next as well.

>> +static int firmware_version_show(struct seq_file *seqf, void *unused)
>> +{
>> +	struct waterforce_data *priv = seqf->private;
>> +
>> +	if (!priv->firmware_version)
>> +		return -ENODATA;
> 
> Maybe don't create the file in the firmware version is not reported.
> Returning an error when trying to read it seems pointless (and confusing).
> 

Agreed. Moved this check into waterforce_debugfs_init() in v3.

>> +
>> +	seq_printf(seqf, "%u\n", priv->firmware_version);
>> +
>> +	return 0;
>> +}
>> +DEFINE_SHOW_ATTRIBUTE(firmware_version);
>> +
>> +static void waterforce_debugfs_init(struct waterforce_data *priv)
>> +{
>> +	char name[64];
>> +
>> +	scnprintf(name, sizeof(name), "%s-%s", DRIVER_NAME, dev_name(&priv->hdev->dev));
>> +
>> +	priv->debugfs = debugfs_create_dir(name, NULL);
>> +	debugfs_create_file("firmware_version", 0444, priv->debugfs, priv, &firmware_version_fops);
>> +}
>> +
>> +#else
>> +
>> +static void waterforce_debugfs_init(struct waterforce_data *priv)
>> +{
>> +}
>> +
>> +#endif
>> +
>> +static int waterforce_probe(struct hid_device *hdev, const struct hid_device_id *id)
>> +{
>> +	struct waterforce_data *priv;
>> +	int ret;
>> +
>> +	priv = devm_kzalloc(&hdev->dev, sizeof(*priv), GFP_KERNEL);
>> +	if (!priv)
>> +		return -ENOMEM;
>> +
>> +	priv->hdev = hdev;
>> +	hid_set_drvdata(hdev, priv);
>> +
>> +	/*
>> +	 * Initialize priv->updated to STATUS_VALIDITY seconds in the past, making
>> +	 * the initial empty data invalid for waterforce_read() without the need for
>> +	 * a special case there.
>> +	 */
>> +	priv->updated = jiffies - msecs_to_jiffies(STATUS_VALIDITY);
>> +
>> +	ret = hid_parse(hdev);
>> +	if (ret) {
>> +		hid_err(hdev, "hid parse failed with %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	/*
>> +	 * Enable hidraw so existing user-space tools can continue to work.
>> +	 */
>> +	ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
>> +	if (ret) {
>> +		hid_err(hdev, "hid hw start failed with %d\n", ret);
>> +		goto fail_and_stop;
>> +	}
>> +
>> +	ret = hid_hw_open(hdev);
>> +	if (ret) {
>> +		hid_err(hdev, "hid hw open failed with %d\n", ret);
>> +		goto fail_and_close;
>> +	}
>> +
>> +	priv->buffer = devm_kzalloc(&hdev->dev, MAX_REPORT_LENGTH, GFP_KERNEL);
>> +	if (!priv->buffer) {
>> +		ret = -ENOMEM;
>> +		goto fail_and_close;
>> +	}
>> +
>> +	mutex_init(&priv->status_report_request_mutex);
>> +	mutex_init(&priv->buffer_lock);
>> +	spin_lock_init(&priv->status_report_request_lock);
>> +	init_completion(&priv->status_report_received);
>> +	init_completion(&priv->fw_version_processed);
>> +
>> +	priv->hwmon_dev = hwmon_device_register_with_info(&hdev->dev, "waterforce",
>> +							  priv, &waterforce_chip_info, NULL);
>> +	if (IS_ERR(priv->hwmon_dev)) {
>> +		ret = PTR_ERR(priv->hwmon_dev);
>> +		hid_err(hdev, "hwmon registration failed with %d\n", ret);
>> +		goto fail_and_close;
>> +	}
>> +
>> +	hid_device_io_start(hdev);
>> +	ret = waterforce_get_fw_ver(hdev);
>> +	if (ret < 0)
>> +		hid_warn(hdev, "fw version request failed with %d\n", ret);
>> +	hid_device_io_stop(hdev);
> 
> Doesn't this interfere with normal hwmon operation if a hwmon request
> is made immediately after hwmon device registration ?
> 

Looks like it does.... I'll move it up before and remove hid_device_io_stop(),
there's no reason to stop the traffic at this point in probe.

Thanks,
Aleksa

>> +
>> +	waterforce_debugfs_init(priv);
>> +
>> +	return 0;
>> +
>> +fail_and_close:
>> +	hid_hw_close(hdev);
>> +fail_and_stop:
>> +	hid_hw_stop(hdev);
>> +	return ret;
>> +}
>> +
>> +static void waterforce_remove(struct hid_device *hdev)
>> +{
>> +	struct waterforce_data *priv = hid_get_drvdata(hdev);
>> +
>> +	hwmon_device_unregister(priv->hwmon_dev);
>> +
>> +	hid_hw_close(hdev);
>> +	hid_hw_stop(hdev);
>> +}
>> +
>> +static const struct hid_device_id waterforce_table[] = {
>> +	{ HID_USB_DEVICE(USB_VENDOR_ID_GIGABYTE, USB_PRODUCT_ID_WATERFORCE) },
>> +	{ }
>> +};
>> +
>> +MODULE_DEVICE_TABLE(hid, waterforce_table);
>> +
>> +static struct hid_driver waterforce_driver = {
>> +	.name = "waterforce",
>> +	.id_table = waterforce_table,
>> +	.probe = waterforce_probe,
>> +	.remove = waterforce_remove,
>> +	.raw_event = waterforce_raw_event,
>> +};
>> +
>> +static int __init waterforce_init(void)
>> +{
>> +	return hid_register_driver(&waterforce_driver);
>> +}
>> +
>> +static void __exit waterforce_exit(void)
>> +{
>> +	hid_unregister_driver(&waterforce_driver);
>> +}
>> +
>> +/* When compiled into the kernel, initialize after the HID bus */
>> +late_initcall(waterforce_init);
>> +module_exit(waterforce_exit);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Aleksa Savic <savicaleksa83@...il.com>");
>> +MODULE_DESCRIPTION("Hwmon driver for Gigabyte AORUS Waterforce AIO coolers");

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ