Kernel driver for corsair coolers about liquidtux HOT 6 CLOSED

I remember seeing these when you opened an issue on lm-sensors.

I'll be happy to accept patches for the hwmon subsystem in the upstream kernel. The drivers pointed to would need some rework, but they are a good start. Please send patches or patch series to [email protected].
—Guenter Roeck, hwmon maintainer, replying to you in lm-sensors#63

Have you made any changes since?

I can probably help out on the clink driver (i.e. H80i GT), assuming I can test it with the device I actually have access to (EVGA CLC 120). That's a newer model of the same Asetek 690LC family, and it seems to be (mostly?) backwards compatible.

But first, what devices do you own and which of the drivers are you using daily?

from liquidtux.

Have you made any changes since?

No, haven't had time to make any changes.

But first, what devices do you own and which of the drivers are you using daily?

I have a Corsair H115i, currently not using any drivers with it.

from liquidtux.

In that case we should just start from scratch if we decide to target the H115i.

Besides the obvious API rot and the ID table confusion (which devices each driver binds to doesn't match the documentation) in the drivers you'll recovered, the protocol implemented for the H80i GT seems alien to me, even though I have done a lot of research on that.

Either the H80i GT uses a different protocol than what's assumed by all projects I'm aware of (thus making it untestable by either of us), or what has been implemented in that driver doesn't work.

The more I look at them, the more I feel that those drivers underwent some (unsuccessful) refactoring before being posted to the forum. The documentation looks nice and I might learn some stuff from the implementation, but in the end I just don't trust them enough to adopt them.

Also, the specific devices these drivers support are pretty old by now and, in the case of the H80i GT with its expected 5-year life span, almost irrelevant.

No, haven't had time to make any changes.

While my EVGA CLC 120 is compatible¹ with the H115i, it's just a test unit to me; I would have no real use for a hwmon driver for either device.

I'm not willing to push this to the front of the queue without some serious commitment from you that you'll help develop and maintain it. A kernel driver is a lot more responsibility and work, and the "take over the world" approach I have in liquidctl does not apply here.

¹ The support for the H115i in liquidctl uses the same driver as the CLC 120, and this has been reported to work well.

from liquidtux.

In that case we should just start from scratch if we decide to target the H115i.

Yeah, I think that seemed like it might be the best approach for the H115i last I looked into it.

Either the H80i GT uses a different protocol than what's assumed by all projects I'm aware of (thus making it untestable by either of us), or what has been implemented in that driver doesn't work.

Seems the clink id matches this liquidctl one while my H115i uses this id. Maybe it's firmware version dependent.

I'm not willing to push this to the front of the queue without some serious commitment from you that you'll help develop and maintain it.

I can help with that, although my c is a bit rusty so not sure how much code I would be able to write. I've debugged kernel drivers before for embedded Linux systems however.

from liquidtux.

Either the H80i GT uses a different protocol than what's assumed by all projects I'm aware of (thus making it untestable by either of us), or what has been implemented in that driver doesn't work.

Seems the clink id matches this liquidctl one while my H115i uses this id. Maybe it's firmware version dependent.

The ID is fine... I mean, expect for the part where the clink driver binds to the H80i GT, while the h80i driver binds to something else.

It's the actual message construction and parsing that seems weird to me.

from liquidtux.

Opened #2 to track the interest for/work on a driver that supports the H115i.

from liquidtux.