C7HWIFI/ROG CROSSHAIR VII HERO (WI-FI): assistance in porting from asus-wmi-sensors

[hanetzer]

Heyo. Above mentioned board is currently supported by the asus-wmi-sensors kmod and I'd like to port it over. However, I'm not sure as to the mapping between the two. I have a dumped and decompiled dsdt table. asus-wmi-sensors gives me:

asus_wmi_sensors-virtual-0
Adapter: Virtual device
CPU Core Voltage:          1.31 V  
CPU SOC Voltage:         796.00 mV 
DRAM Voltage:              1.18 V  
VDDP Voltage:            556.00 mV 
1.8V PLL Voltage:          1.81 V  
+12V Voltage:             12.10 V  
+5V Voltage:               4.99 V  
3VSB Voltage:              3.31 V  
VBAT Voltage:              3.18 V  
AVCC3 Voltage:             3.31 V  
SB 1.05V Voltage:          1.07 V  
CPU Core Voltage:          1.34 V  
CPU SOC Voltage:         818.00 mV 
DRAM Voltage:              1.20 V  
CPU Fan:                 1305 RPM
Chassis Fan 1:            901 RPM
Chassis Fan 2:            820 RPM
Chassis Fan 3:              0 RPM
HAMP Fan:                   0 RPM
Water Pump:                 0 RPM
CPU OPT:                    0 RPM
Water Flow:              1114 RPM
AIO Pump:                1137 RPM
CPU Temperature:          +35.0°C  
CPU Socket Temperature:   +36.0°C  
Motherboard Temperature:  +31.0°C  
Chipset Temperature:      +42.0°C  
Tsensor 1 Temperature:   +216.0°C  
CPU VRM Temperature:      +36.0°C  
Water In:                +216.0°C  
Water Out:               +216.0°C  
CPU VRM Output Current:    4.00 A  

with a small patch:

diff --git a/asus-ec-sensors.c b/asus-ec-sensors.c
index 2768b75..43f8632 100644
--- a/asus-ec-sensors.c
+++ b/asus-ec-sensors.c
@@ -311,6 +311,15 @@ static const struct ec_board_info board_info_pro_ws_x570_ace = {
    .family = family_amd_500_series,
 };

+static const struct ec_board_info board_info_crosshair_vii_hero = {
+   .sensors = SENSOR_SET_TEMP_CHIPSET_CPU_MB |
+       /* SENSOR_TEMP_T_SENSOR |SENSOR_FAN_CHIPSET, */
+       SENSOR_TEMP_VRM | SENSOR_SET_TEMP_WATER |
+       SENSOR_FAN_CPU_OPT | SENSOR_CURR_CPU,
+   .mutex_path = ASUS_HW_ACCESS_MUTEX_ASMX,
+   .family = family_amd_400_series,
+};
+
 static const struct ec_board_info board_info_crosshair_viii_dark_hero = {
    .sensors = SENSOR_SET_TEMP_CHIPSET_CPU_MB |
        SENSOR_TEMP_T_SENSOR |
@@ -437,6 +446,8 @@ static const struct dmi_system_id dmi_table[] = {
                    &board_info_pro_art_x570_creator_wifi),
    DMI_EXACT_MATCH_ASUS_BOARD_NAME("Pro WS X570-ACE",
                    &board_info_pro_ws_x570_ace),
+   DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR VII HERO (WI-FI)",
+                   &board_info_crosshair_vii_hero),
    DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR VIII DARK HERO",
                    &board_info_crosshair_viii_dark_hero),
    DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR VIII FORMULA",

I get the following output:

asusec-isa-0000
Adapter: ISA adapter
CPU_Opt:        0 RPM
Chipset:      +42.0°C  
CPU:          +35.0°C  
Motherboard:  +31.0°C  
VRM:          +36.0°C  
Water_In:      +0.0°C  
Water_Out:     +0.0°C  
CPU:           5.00 A  

It would be helpful if there was a small guide on figuring out what is supported. I thought I'd just enable it all and see what doesn't work but boy did my kernel not like that.

[zeule]

Thank you for the contribution! Why do you want to ditch the asus-emi-sensors driver? Two drivers covering the same board is not exactly what mainline kernel project likes; to submit such a change I need a reason. There has to be a table in the DSDT that maps those labels to EC register indices. I can find it later today. I'm interested to know details what went bad when you tried to read all the possible sensors. To my knowledge that should not cause problems unless we try to read EC banks which do not exist.

[hanetzer]

I've figured it out, I think. And I thought the asus-wmi-sensors kmod was getting retired in favor of this one? In any case, its mostly about me wanting to 'pick apart' this machine as much as possible, since I'm planning on doing some hw/fw dev on/for it.

[zeule]

And I thought the asus-wmi-sensors kmod was getting retired in favor of this one?

No, it was not. asus-wmi-sensors provides the full set of sensor readings, combining those from the Super I/O chip and the EC.

[hanetzer]

https://www.phoronix.com/news/Linux-Drop-ASUS-WMI-EC-Sensors Ah, I missed a segment of the name reading this.

[hanetzer]

so, while I have the semi-attention of a low level kernel/firmware interaction developer. Hypothetically speaking, if one were to port any of the boards supported by either this driver or asus-wmi-sensors to coreboot/oreboot/whatever, what then? Should one at that point use the asus-ec-sensors and the whatever-your-superio-is driver? Or should the *boot porter replicate the wmi interface from the vendor bios?

[zeule]

The less logic is in the firmware, where it is harder to change it that in the software, the better. How important for Coreboot to replicate DMI interfaces of the original BIOSes I can't tell.