nzxt-kraken3 upstreaming? about liquidtux

[aleksamagicka]

I have to bring #44 over the finish line and retest everything. I've been finishing up other projects I had, so I hope I'll tackle it this month. Also, 6.3 merge window just opened, so whatever I send for upstreaming will be on hold for the next two weeks or so, and the earliest this could get in is 6.4.

[aleksamagicka]

Here's the current version of the v1 patch for mainlining this:

v1_nzxt-kraken3.txt

And it's also available in my linux repo and in #43.

[aleksamagicka]

Splendid, thank you. Ordered one!

[amezin]

BTW, maybe we should have something like stable-queue repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ - where kernel patches will be prepared for submission

[stalkerg]

@jonasmalacofilho I did it here #9 (comment)

[lfitt]

Hi team, I grabbed kernel 6.2.1, threw nzxt-kraken3.c into the right place, updated the Makefile for the kernel, built the whole thing and it's in the kernel and running happily.

from sensors:
x53-hid-3-8
Adapter: HID adapter
Pump speed: 2083 RPM
Coolant temp: +32.8°C

fancontrol-gui lets me set pump speed and system fan speeds based on coolant temperature. The only "weirdness" is the pump shows up as a second "fan1" - but that might be the GUI, not the module.

Setting the pump speed of the second "fan1" appears to work correctly (ie: dropping the pump speed increases the coolant temp, increasing the pump speed lowers the coolant temp)

Thanks for all of your work, I appreciate it!

[aleksamagicka]

Thanks, appreciate the testing. There's still a PR that needs to be reviewed and once that goes through, we should be able to mainline this.

[stalkerg]

@aleksamagicka yes, please - Yury Zhuravlev <[email protected]> for all tags.

Thank you.

[jonasmalacofilho]

That would be great, actually. Thanks!

[aleksamagicka]

I think the driver is generally in a good state for sending a v1 (once #29 is in) to get some comments in the worst case. What do you think about this draft of a cover message for LKML?

This driver enables hardware monitoring support for NZXT Kraken X53/X63/X73
and Z53/Z63/Z73 all-in-one CPU liquid coolers. All models expose liquid
temperature and pump speed (in RPM), as well as PWM control (either as
a fixed value or through a temp-PWM curve). The Z-series models
additionally expose the speed and duty of an optionally connected fan,
with the same PWM control capabilities.

Pump and fan duty control mode can be set through pwm[1-2]_enable,
where 1 is for the manual control mode and 2 is for the liquid temp
to PWM curve mode. Writing a 0 disables control of the channel through
the driver after setting its duty to 100%.

The temperature of the curves relates to the fixed [20-59] range,
correlating to the detected liquid temperature. Only PWM values
(ranging from 0-255) can be set.

The addressable RGB LEDs and LCD screen, included only on Z-series models,
are not supported in this driver.

Signed-off-by: Jonas Malaco <[email protected]>
Signed-off-by: Aleksa Savic <[email protected]>

---

One issue we might hit is that we don't expose the temp points of the curves as sysfs entries, like we do for their PWM counterparts. Perhaps Guenter will want us to expose them, even if they are read only. The reason I'm not implementing that preemptively is because we'd then need to dynamically create the curves in sysfs to avoid having hundreds of lines of manual definitions, and I'd like to possibly discuss that approach/get hints from him.

Here's how the boilerplate for that looks like. It's taken from one his drivers where it would be too unwieldy to define them all statically.

[stalkerg]

Looks good to me.

PS with fan2go basically the temp curve on the driver's side is useless. pwm[1-*]_auto_channels_temp also not usable because the number of the sensor can be changed after reboot.

[aleksamagicka]

Thanks. Why would the number of the sensor change? AFAIK it only has one, the coolant temp?

[stalkerg]

For some reason, sensors can register in different orders and use different numbers, but the number of sensors is the same.

[aleksamagicka]

From the viewpoint of the driver, what sensors? pwm[1-*]_auto_channels_temp is used to set the reference device temp sensor for a particular curve on the device, and the X series devices only have one - the coolant temp, so the only value that could possibly have is 1. I haven't used fan2go so I'm not sure if you referring to something from there.

[jonasmalacofilho]

@aleksamagicka ,

I think the driver is generally in a good state for sending a v1 (once #29 is in) to get some comments in the worst case. What do you think about this draft of a cover message for LKML?

I would complement it by mentioning the few behaviors that might be non-standard for hwmon drivers (e.g. keeping track of the control mode, or that the fixed temperature interval for fan control curves is a device limitation).

What do you think about this draft?

This driver enables hardware monitoring support for NZXT Kraken
X53/X63/X73 and Z53/Z63/Z73 all-in-one CPU liquid coolers.

All models expose liquid temperature and pump speed (in RPM), as well as
PWM control (natively only through a temp-PWM curve, but the driver also
emulates fixed PWM control on top of that). The Z-series models
additionally expose the speed and duty of an optionally connected fan,
with the same PWM control capabilities.

Pump and fan duty control mode can be set through pwm[1-2]_enable,
where 1 is for the manual control mode and 2 is for the liquid temp
to PWM curve mode. Writing a 0 disables control of the channel through
the driver after setting its duty to 100%. As it is not possible to query
the device for the active mode, the driver keeps track of it.

The temperature of the curves relates to the fixed [20-59] °C range, per
device limitations, and correlating to the detected liquid temperature.
Only PWM values (ranging from 0-255) can be set.

The addressable RGB LEDs and LCD screen, included only on Z-series models,
are not supported in this driver.

Signed-off-by: Jonas Malaco <[email protected]>
Signed-off-by: Aleksa Savic <[email protected]>

---

One issue we might hit is that we don't expose the temp points of the curves as sysfs entries, like we do for their PWM counterparts. Perhaps Guenter will want us to expose them, even if they are read only. The reason I'm not implementing that preemptively is because we'd then need to dynamically create the curves in sysfs to avoid having hundreds of lines of manual definitions, and I'd like to possibly discuss that approach/get hints from him.

Agreed.

[aleksamagicka]

Looks good to me - I'll prepare a patch.

[aleksamagicka]

Here is the patch: nzxt-kraken3.txt

If everything looks good, that's what I'll send.

[jonasmalacofilho]

@aleksamagicka, LGTM, but I think I'm missing a Co-developed-by tag as well:

Co-developed-by: Jonas Malaco <[email protected]>
Signed-off-by: Jonas Malaco <[email protected]>
Signed-off-by: Aleksa Savic <[email protected]>

(That is, assuming your intention with the Signed-off-by tag was to refer to my early work on what eventually became this patch/driver).

---

From Submitting patches: [...]:

Any further SoBs (Signed-off-by:’s) following the author’s SoB are from people handling and transporting the patch, but were not involved in its development.

Co-developed-by: states that the patch was co-created by multiple developers; it is used to give attribution to co-authors (in addition to the author attributed by the From: tag) when several people work on a single patch. Since Co-developed-by: denotes authorship, every Co-developed-by: must be immediately followed by a Signed-off-by: of the associated co-author. [...]

[stalkerg]

Probably, I also should be mentioned here.

[jonasmalacofilho]

@stalkerg, sorry about that!

Please provide your desired Co-developed-by & Signed-off-by tags after reading, if you haven't already done so, their requirements and implications.

---

@amezin, you also have a few commits touching this driver. Let me know how you would like us to handle that.

[amezin]

My changes were few, small and trivial. Not worth mentioning IMO

[aleksamagicka]

@jonasmalacofilho Thanks! Added. (Only used From: before.)

@stalkerg Sorry about that! I'm under barrage of college finals and forgot to check the history once more. Added you now. Here's how the same patch currently looks, although there's more work to do: nzxt-kraken3.txt

[stalkerg]

@aleksamagicka, no problem looks good.

[aleksamagicka]

This should be the latest patch: nzxt-kraken3_v3.txt and that's what I'll send if there are no objections (v3 here is just for the filename).

pwmconfig isn't really smart and gets some RPMs wrong during its autodetection, but fancontrol works with no errors. fan2go is the superior option overall.

[amezin]

pwmconfig ... gets some RPMs wrong during its autodetection

Could you tell a bit more about that?

If I'm not mistaken, return -ENODATA from sysfs read made fancontrol exit immediately, and that's why I have a waitqueue in my driver.

Why isn't wait_for_completion() performed for all devices?

[aleksamagicka]

Hm, sorry for the noise. Testing again, looks like it doesn't save the config for me. Will have to investigate further, but I first have to sort out nvidia and newer kernels on my Fedora install or just switch to a VM. The output of pwmconfig could be better IMHO, looks like it discards something :/

Currently wait_for_completion() is for getting the z53 status on demand, but perhaps we'll need it for x53 as well.

Edit: to clarify the autodetection remarks, it looked like it didn't believe some of the values, even though they are the correct ones for the PWM value it set.

[amezin]

@aleksamagicka BTW, could you create a pull request, adding the patch to patches/ directory in the repository (there's no directory yet, you'll have to create it)?

#31 (comment)

[stalkerg]

What status?

[stalkerg]

@aleksamagicka just in case, should be my "Signed-off-by" in such a patch as well?

[aleksamagicka]

I can add your Co-developed-by: and Signed-off-by: tags if you wish (here's the formal definition), just leave your email/tags here.

But I'll do that in the next patch version, since the linked one predates #56. (Which reminds me to ping Guenter about a similar patch.)