On 20/10/2022 21:04, Denis Pauk wrote:
On Thu, 20 Oct 2022 18:08:00 +0100
Ahmad Khalifa <ahmad@xxxxxxxxxx> wrote:
On 19/10/2022 22:04, Denis Pauk wrote:
Hi Ahmad,
Thank you for your patch.
I will add mention of you patch in
https://bugzilla.kernel.org/show_bug.cgi?id=204807 also.
That's an interesting bug. It has loads of ACPI tables in there, which
could be very useful.
The acpi patch is still a proof of concept and will show wrong values, I
know the voltages and temperatures are mixed up or could even be pulling
rubbish data that looks like a temperature.
I just wanted comments on where to go, thanks for the below.
There is definitely lots to fix up first.
You also can use https://github.com/asus-wmi-boards-sensors/asus-board-dsdt, I
have collected DSDT from bugs and asus support site. I suppose
that all ASUS X670 bioses will have same dsdt definitions.
This is massive, extracted and all. I'll need to go through this for
sure. Many thanks for this repo.
I don't think the X670 platform motherboards will have the same ACPI
tables. For example, ATX vs ITX, STRIX vs CROSSHAIR, different
peripherals/configurations.
Some of dumps contains register definition like in P8H67-ASUS:
```
IndexField (HIDX, HDAT, ByteAcc, NoLock, Preserve)
{
Offset (0x04),
CHNM, 1,
....
VCOR, 8,
V12V, 8,
Offset (0x23),
V33V, 8,
V50V, 8,
....
}
```
On Tue, Oct 18, 2022 at 06:34:29PM +0100, Ahmad Khalifa wrote:
New Asus X670 board firmware doesn't expose the WMI GUID used for the
SIO/HWM methods. The driver's GUID isn't in the ACPI tables and the
GUIDs that do exist do not expose the RSIO/WSIO and RHWM/WHWM methods
(which do exist with same IDs).
Have you caught differences in DSDT definition that broke WMI call?
I see similar definition of WMI methods in X570 and X670 dsdt and by first look
everything should be good.
It looks like WMI, but the GUID below is pointing at WMBC only, whereas
you'd expect the 'BD' characters to be in there to access it through the
WMI bus.
The hwmon drivers point at:
nct6775: 466747A0-70EC-11DE-8A39-0800200C9A66
asus_wmi_sensors: 466747A0-70EC-11DE-8A39-0800200C9A66
but the new board (from below) has:
X670 : 97845ED0-4E6D-11DE-8A39-0800200C9A66
The change in the first 2 segments might be indicative here, hence why I
didn't think they just 'forgot' the GUID in this firmware
Anyway way, Geunter's idea from the other thread about reaching for the
read/write methods directly might just be better here. No need to
struggle with GUIDs that can change if Asus will always expose the
methods. I'll go through your repo and see if I can confirm that.
Like:
X670
```
....
Name (_HID, EisaId ("PNP0C14") /* Windows Management Instrumentation Device */)
// _HID: Hardware ID
Name (_UID, "AsusMbSwInterface") // _UID: Unique ID
Name (_WDG, Buffer (0x3C)
{
/* 0000 */ 0xD0, 0x5E, 0x84, 0x97, 0x6D, 0x4E, 0xDE, 0x11, // .^..mN..
/* 0008 */ 0x8A, 0x39, 0x08, 0x00, 0x20, 0x0C, 0x9A, 0x66, // .9.. ..f
/* 0010 */ 0x42, 0x43, 0x01, 0x02, 0x72, 0x0F, 0xBC, 0xAB, // BC..r...
/* 0018 */ 0xA1, 0x8E, 0xD1, 0x11, 0x00, 0xA0, 0xC9, 0x06, // ........
/* 0020 */ 0x29, 0x10, 0x00, 0x00, 0xD2, 0x00, 0x01, 0x08, // ).......
/* 0028 */ 0x21, 0x12, 0x90, 0x05, 0x66, 0xD5, 0xD1, 0x11, // !...f...
/* 0030 */ 0xB2, 0xF0, 0x00, 0xA0, 0xC9, 0x06, 0x29, 0x10, // ......).
/* 0038 */ 0x4D, 0x4F, 0x01, 0x00 // MO..
})
.....
Method (WMBD, 3, Serialized)
{
Local0 = One
Switch (Arg1)
{
....
Case (0x5253494F) +
{
Return (RSIO (Arg2))
}
Case (0x5753494F) +
{
Return (WSIO (Arg2))
}
Case (0x5248574D) +
{
Return (RHWM (Arg2))
}
Case (0x5748574D) +
{
Return (WHWM (Arg2))
}
......
Default
{
Return (Zero)
}
}
Return (Local0)
}
```
--
Regards,
Ahmad
