Re: [PATCH] hwmon: (aquacomputer_d5next) Add support for Aquacomputer Farbwerk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/23/22 20:47, Jack Doan wrote:
On 4/23/22 20:42, Guenter Roeck wrote:

On Thu, Apr 21, 2022 at 09:27:42AM +0200, Aleksa Savic wrote:
Extend aquacomputer_d5next driver to expose hardware temperature sensors
of the Aquacomputer Farbwerk RGB controller, which communicates through
a proprietary USB HID protocol.

Four temperature sensors are available. Additionally, serial number and
firmware version are exposed through debugfs.

Also, add Jack Doan to MAINTAINERS for this driver.

Signed-off-by: Jack Doan<me@xxxxxxxxxxxx>
Signed-off-by: Aleksa Savic<savicaleksa83@xxxxxxxxx>
---
This patch doesn't apply. Please rebase to master and resend.
Will do!
More comments inline.

If adding to MAINTAINERS requires a separate commit, I'll send it
separately.
---
  Documentation/hwmon/aquacomputer_d5next.rst |  3 +-
  MAINTAINERS                                 |  1 +
  drivers/hwmon/Kconfig                       |  5 +--
  drivers/hwmon/aquacomputer_d5next.c         | 37 ++++++++++++++++++---
  4 files changed, 38 insertions(+), 8 deletions(-)

diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst
index e69f718caf5b..717e28226cde 100644
--- a/Documentation/hwmon/aquacomputer_d5next.rst
+++ b/Documentation/hwmon/aquacomputer_d5next.rst
@@ -6,6 +6,7 @@ Kernel driver aquacomputer-d5next
  Supported devices:
* Aquacomputer D5 Next watercooling pump
+* Aquacomputer Farbwerk RGB controller
  * Aquacomputer Farbwerk 360 RGB controller
  * Aquacomputer Octo fan controller
@@ -32,7 +33,7 @@ better suited for userspace tools.
  The Octo exposes four temperature sensors and eight PWM controllable fans, along
  with their speed (in RPM), power, voltage and current.
-The Farbwerk 360 exposes four temperature sensors. Depending on the device,
+The Farbwerk and Farbwerk 360 expose four temperature sensors. Depending on the device,
  not all sysfs and debugfs entries will be available.
Usage notes
diff --git a/MAINTAINERS b/MAINTAINERS
index ea2cd656ee6c..d8e3ca0fbc3a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1389,6 +1389,7 @@ F:	drivers/media/i2c/aptina-pll.*
AQUACOMPUTER D5 NEXT PUMP SENSOR DRIVER
  M:	Aleksa Savic<savicaleksa83@xxxxxxxxx>
+M:	Jack Doan<me@xxxxxxxxxxxx>
  L:	linux-hwmon@xxxxxxxxxxxxxxx
  S:	Maintained
  F:	Documentation/hwmon/aquacomputer_d5next.rst
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5beadd8a0932..01d10c9b633a 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -256,12 +256,13 @@ config SENSORS_AHT10
  	  will be called aht10.
config SENSORS_AQUACOMPUTER_D5NEXT
-	tristate "Aquacomputer D5 Next, Octo and Farbwerk 360"
+	tristate "Aquacomputer D5 Next, Octo, Farbwerk, Farbwerk 360"
  	depends on USB_HID
  	help
  	  If you say yes here you get support for sensors and fans of
  	  the Aquacomputer D5 Next watercooling pump, Octo fan
-	  controller and Farbwerk 360 RGB controller, where available.
+	  controller, Farbwerk and Farbwerk 360 RGB controllers, where
+	  available.
This driver can also be built as a module. If so, the module
  	  will be called aquacomputer_d5next.
diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
index a464473bc981..7d2e7279abfb 100644
--- a/drivers/hwmon/aquacomputer_d5next.c
+++ b/drivers/hwmon/aquacomputer_d5next.c
@@ -1,11 +1,12 @@
  // SPDX-License-Identifier: GPL-2.0+
  /*
- * hwmon driver for Aquacomputer devices (D5 Next, Farbwerk 360, Octo)
+ * hwmon driver for Aquacomputer devices (D5 Next, Farbwerk, Farbwerk 360, Octo)
   *
   * Aquacomputer devices send HID reports (with ID 0x01) every second to report
   * sensor values.
   *
   * Copyright 2021 Aleksa Savic<savicaleksa83@xxxxxxxxx>
+ * Copyright 2022 Jack Doan<me@xxxxxxxxxxxx>
That is a bit aggressive for a few lines of code.
Addressed below.
   */
#include <linux/crc16.h>
@@ -19,14 +20,16 @@
  #include <asm/unaligned.h>
#define USB_VENDOR_ID_AQUACOMPUTER 0x0c70
+#define USB_PRODUCT_ID_FARBWERK		0xf00a
  #define USB_PRODUCT_ID_D5NEXT		0xf00e
  #define USB_PRODUCT_ID_FARBWERK360	0xf010
  #define USB_PRODUCT_ID_OCTO		0xf011
-enum kinds { d5next, farbwerk360, octo };
+enum kinds { d5next, farbwerk, farbwerk360, octo };
static const char *const aqc_device_names[] = {
  	[d5next] = "d5next",
+	[farbwerk] = "farbwerk",
  	[farbwerk360] = "farbwerk360",
  	[octo] = "octo"
  };
@@ -69,6 +72,12 @@ static u8 secondary_ctrl_report[] = {
  #define D5NEXT_PUMP_CURRENT		112
  #define D5NEXT_FAN_CURRENT		99
+/* Register offsets for the Farbwerk RGB controller */
+#define FARBWERK_NUM_SENSORS		4
+#define FARBWERK_SENSOR_START		0x2f
+#define FARBWERK_SENSOR_SIZE		0x02
+#define FARBWERK_SENSOR_DISCONNECTED	0x7FFF
+
  /* Register offsets for the Farbwerk 360 RGB controller */
  #define FARBWERK360_NUM_SENSORS		4
  #define FARBWERK360_SENSOR_START	0x32
@@ -125,7 +134,7 @@ static const char *const label_d5next_current[] = {
  	"Fan current"
  };
-/* Labels for Farbwerk 360 and Octo temperature sensors */
+/* Labels for Farbwerk, Farbwerk 360 and Octo temperature sensors */
  static const char *const label_temp_sensors[] = {
  	"Sensor 1",
  	"Sensor 2",
@@ -319,6 +328,7 @@ static umode_t aqc_is_visible(const void *data, enum hwmon_sensor_types type, u3
  			if (channel == 0)
  				return 0444;
  			break;
+		case farbwerk:
  		case farbwerk360:
  		case octo:
  			return 0444;
@@ -551,8 +561,7 @@ static const struct hwmon_chip_info aqc_chip_info = {
  	.info = aqc_info,
  };
-static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8 *data,
-			 int size)
+static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8 *data, int size)
  {
  	int i, sensor_value;
  	struct aqc_data *priv;
@@ -587,6 +596,17 @@ static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8
  		priv->current_input[0] = get_unaligned_be16(data + D5NEXT_PUMP_CURRENT);
  		priv->current_input[1] = get_unaligned_be16(data + D5NEXT_FAN_CURRENT);
  		break;
+	case farbwerk:
+		/* Temperature sensor readings */
+		for (i = 0; i < FARBWERK_NUM_SENSORS; i++) {
+			sensor_value = get_unaligned_be16(data + FARBWERK_SENSOR_START +
+							  i * FARBWERK_SENSOR_SIZE);
+			if (sensor_value == FARBWERK_SENSOR_DISCONNECTED)
+				priv->temp_input[i] = -ENODATA;
Can the sensor be connected dynamically ? If not, this should be handled
in an is_visible function.
It's a somewhat unlikely use-case, but yes, they can be. The sensors are NTC thermistors that connect to pin-headers. Do we have a better way of representing "open circuit" than -ENODATA?

Seems to be a bit theoretic to assume that someone would play with
connecting and disconnecting cables while the system is running.
Have you tried to do that ? It would be interesting to know if
the controller handles that situation. But don't blame me
if you fry your system :-)

Anyway, there could be a tempX_fault attribute which would return 1
in that case. Not sure if that makes more sense, though.

+			else
+				priv->temp_input[i] = sensor_value * 10;
+		}
+		break;
  	case farbwerk360:
  		/* Temperature sensor readings */
  		for (i = 0; i < FARBWERK360_NUM_SENSORS; i++) {
@@ -733,6 +753,11 @@ static int aqc_probe(struct hid_device *hdev, const struct hid_device_id *id)
  		priv->voltage_label = label_d5next_voltages;
  		priv->current_label = label_d5next_current;
  		break;
+	case USB_PRODUCT_ID_FARBWERK:
+		priv->kind = farbwerk;
+
+		priv->temp_label = label_temp_sensors;
+		break;
  	case USB_PRODUCT_ID_FARBWERK360:
  		priv->kind = farbwerk360;
@@ -795,6 +820,7 @@ static void aqc_remove(struct hid_device *hdev) static const struct hid_device_id aqc_table[] = {
  	{ HID_USB_DEVICE(USB_VENDOR_ID_AQUACOMPUTER, USB_PRODUCT_ID_D5NEXT) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_AQUACOMPUTER, USB_PRODUCT_ID_FARBWERK) },
  	{ HID_USB_DEVICE(USB_VENDOR_ID_AQUACOMPUTER, USB_PRODUCT_ID_FARBWERK360) },
  	{ HID_USB_DEVICE(USB_VENDOR_ID_AQUACOMPUTER, USB_PRODUCT_ID_OCTO) },
  	{ }
@@ -826,4 +852,5 @@ module_exit(aqc_exit);
MODULE_LICENSE("GPL");
  MODULE_AUTHOR("Aleksa Savic<savicaleksa83@xxxxxxxxx>");
+MODULE_AUTHOR("Jack Doan<me@xxxxxxxxxxxx>");
.... as is claiming authorship. I'd be the "author" of hundreds of kernel
files if I would do that. Aleksa signed off on it, so I'll accept it,
but I don't think it is appropriate.
In the context of just this patch, yes, I agree. But, I felt it was warranted based on my previous contributions. I did a good bit of the reverse-engineering that made writing settings to these devices possible, and a lot of the previously submitted code for writing the setting changes is mine as well.

I didn't mean to make an inappropriate request though! If you'd like, I can submit a version of the patch without these lines.

No, I think that makes sense as long as Aleksa is ok with it.

Guenter

  MODULE_DESCRIPTION("Hwmon driver for Aquacomputer devices");




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux