[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #32 from Zhang Rui (rui.zhang@intel.com) ---
Reassign to platform driver category.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Matthew Garrett (mjg59-kernel@srcf.ucam.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |mjg59-kernel@srcf.ucam.org
         Resolution|---                         |INVALID

--- Comment #33 from Matthew Garrett (mjg59-kernel@srcf.ucam.org) ---
This isn't a bug - the ACPI tables claim the resource in question, and there's
no way we can verify there are no conflicts between ACPI methods that touch
that range and the native driver. If you're confident that this is safe on your
system then you can boot with acpi_enforce_resources=lax, but we can't make
that the default. This will still produce the warning, but the driver will be
permitted to load.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Artem S. Tashkinov (aros@gmx.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |torvalds@linux-foundation.o
                   |                            |rg
         Resolution|INVALID                     |---

--- Comment #34 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Matthew Garrett from comment #33)
> This isn't a bug - the ACPI tables claim the resource in question, and
> there's no way we can verify there are no conflicts between ACPI methods
> that touch that range and the native driver. If you're confident that this
> is safe on your system then you can boot with acpi_enforce_resources=lax,
> but we can't make that the default. This will still produce the warning, but
> the driver will be permitted to load.

This bug needs to be fixed because

1) It doesn't affect Windows
2) Average people will never know how to deal with issue
3) I cannot ask my motherboard vendor (ASUS) to fix this issue in BIOS because
they don't provide support for Linux - they barely provide any support at all.

OoB experience of Linux users should not be "I don't get any sensors output,
how to fix that?" Most users don't even know what and how to Google. They don't
know about dmesg either.

That's an effing horrible attitude.

I'm CC'ing Linus because I absolutely hate what's going on.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #35 from Artem S. Tashkinov (aros@gmx.com) ---
This might not be a classic "bug" but **no one on Earth cares**. What people
care about is having their systems work and be supported by Linux out of the
box with **no cryptic voodoo applied**. You don't ask Windows users to run
bcdedit.exe to fix their hardware, do you?

So, why do Linux users have to edit system configuration files to get at least
comparable experience? Don't get me started that HWiNFO64 shows up to ten times
more hardware sensors and their parameters than lm-sensors.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #36 from Artem S. Tashkinov (aros@gmx.com) ---
Lastly, this problem affects literally hundreds of thousands of systems. It's
not some single broken motherboard or broken EFI, we're talking about multiple
classes of hardware.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Matthew Garrett (mjg59-kernel@srcf.ucam.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #37 from Matthew Garrett (mjg59-kernel@srcf.ucam.org) ---
Here's the situation. Your ACPI tables declare that your system firmware may
access the addresses associated with your IO sensors. We have no idea what your
firmware may do here - it may do nothing (in which case accessing the addresses
is completely safe), or it may use them for its own internal monitoring. Sensor
hardware frequently uses indexed addressing, which means that accessing a
sensor requires something like the following:

1) Write the desired sensor to the index register
2) Read the sensor value from the data register

These can't occur simultaneously, so if both the OS and the firmware are
accessing it you risk ending up with something like:

1) Write sensor A to the index register (from the OS)
2) Write sensor B to the index register (from the firmware)
3) Read the sensor value from the data register (returns the value of sensor B
to the firmware)
4) Read the sensor value from the data register (returns the value of sensor B
to the OS)

The OS asked for the value of sensor A, but received the value of sensor B.
From the OS side this is probably not a big deal (you get a weird value in your
graphing), but if it happens the other way around the firmware may decide that
the system is running out of spec and shut it down to avoid damage. This is not
a good user experience.

Why does Windows not have the same problem? Well, in the general case there's
nothing stopping it from doing so. Vendor tooling usually takes one of two
approaches:

1) They don't use the hardware sensors directly, they use firmware interfaces
to them. This is alluded to in comment #31 - on Asus systems, the sensors are
available via a WMI interface. Using a firmware interface ensures that the
firmware knows what the state of the hardware is, and avoids any race
conditions. Your board may well support an alternative firmware interface and
Linux simply lacks driver support for it. If so, I'm afraid that the correct
solution is to add that driver support. Given that this bug has ended up
covering boards from multiple vendors, it's no longer the correct place to
handle that, though.
2) The vendor knows that the firmware makes no policy decisions based on the
sensor values, so it's safe to access the resources even though the firmware
declares that it uses them. The problem with this approach is that *we* have no
way of knowing that it's safe, and the consequences of it being unsafe include
data loss. Given the choice between users being able to look at system
temperatures and users not losing data, we choose to prioritise users not
losing data.

Looking at your ACPI tables, we see the following:

    Name (IOHW, 0x0290)

    OperationRegion (SHWM, SystemIO, IOHW, 0x0A)
    Field (SHWM, ByteAcc, NoLock, Preserve)
    {
        Offset (0x05), 
        HIDX,   8, 
        HDAT,   8
    }

This means that there's a region of IO ports starting at address 0x290 and 0x0a
addresses long. This is the same region of port IO that your sensor chip uses.
Within that address range, we declare that 0x295 is called HIDX, and 0x296 is
called HDAT. This is consistent with an index and data register as described
above, which means that having the OS access this space directly is likely to
race with the firmware (ie, it's dangerous).

Near here are two methods called RHWM and WHWM. At a guess, that's "Read
Hardware Monitoring" and "Write Hardware Monitoring". These not only access the
sensors via the registers described above, they do some additional hardware
access around it. This is further evidence to support there being some
handshaking involved to avoid race conditions - the firmware takes a mutex and
appears to hit some other register that may also be used to guard against
racing against system management mode. We really, *really* want to be using the
firmware methods here rather than touching the sensor chip directly. At this
point, direct access isn't so much walking past a sign saying "Danger, keep
out", it's a sign saying "Proceed no further or you will die slowly and it will
hurt the entire time".

RHWM is referenced from the WMBD method if the first argument to it is RHWM,
and WHWM is referenced if the argument is WHWM. WMBD is the WMI dispatcher for
the WMI function with identifier "BD" - looking at your _WDG object, which
describes the available WMI interfaces, we have the following:

            Name (_WDG, Buffer (0x50)
            {
                /* 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, 0xA0, 0x47, 0x67, 0x46,  //
BC...GgF
                /* 0018 */  0xEC, 0x70, 0xDE, 0x11, 0x8A, 0x39, 0x08, 0x00,  //
.p...9..
                /* 0020 */  0x20, 0x0C, 0x9A, 0x66, 0x42, 0x44, 0x01, 0x02,  //
 ..fBD..
                /* 0028 */  0x72, 0x0F, 0xBC, 0xAB, 0xA1, 0x8E, 0xD1, 0x11,  //
r.......
                /* 0030 */  0x00, 0xA0, 0xC9, 0x06, 0x29, 0x10, 0x00, 0x00,  //
....)...
                /* 0038 */  0xD2, 0x00, 0x01, 0x08, 0x21, 0x12, 0x90, 0x05,  //
....!...
                /* 0040 */  0x66, 0xD5, 0xD1, 0x11, 0xB2, 0xF0, 0x00, 0xA0,  //
f.......
                /* 0048 */  0xC9, 0x06, 0x29, 0x10, 0x4D, 0x4F, 0x01, 0x00   //
..).MO..
            })

The format of _WDG is 16 bytes of GUID, 2 bytes of ID or notification data, 1
byte of instance count and 1 byte of flags. The GUID used by asus-wmi
corresponds to the first GUID in this file,
97845ED0-4E6D-11DE-8A39-0800200C9A66. That has an ID of 0x4243, or BC - ie,
it's not the GUID we're looking for. The next GUID, however,
(466747a0-70ec-11de-8a39-0800200c9a66) has an identifier of 0x4344, or BD. So
this is the GUID we're looking for. Unfortunately asus-wmi doesn't handle this
GUID, so new code will need to be written.

I'm going to close this bug again because it's turned into a generic bug
covering different motherboard vendors, and there's no one size fits all
solution. For your case the correct way to handle it is for someone to write a
driver that uses the 466747a0-70ec-11de-8a39-0800200c9a66 interface to expose
the sensor data. I'm afraid I don't have relevant hardware so can't do this
myself, but please do open another bug for that.

tl;dr - the kernel message you're seeing is correct. Avoiding it requires a new
driver to be written. If you *personally* feel safe in ignoring the risks, you
can pass the acpi_enforce_resources=lax option, but that can't be the default
because it's unsafe in the general case, and so it isn't the solution to the
wider problem.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #38 from Jaap de Haan (jaap.dehaan@freenet.de) ---
CONFIG_ASUS_WMI=m andI confirmed the module is loaded.

I think I saw some improvements lastly in the support of temperature sensors, I
am not so sure because I have no traces of the old state and it's a long time
ago I used the UI. I flashed my BIOS recently and hoped things would be solved
with that action.

Thanks a lot Matthew for this good explanation and for the first time I
understood (at abstract level) what is going on and why it is so. This
explanation is something really valuable to be kept and put in a prominent
place like kernel Documentation and a known issues text file (then a less asus
specific explanation) IMO.

I was nearly as desperate to try to use the `acpi_enforce_resources=lax`
setting but without understanding it is for me as an engineer something "hot"
and now I really get why it is so, I will for my part keep my fingers away from
the setting and hope that someone will find out how to get the FAN values in
the normal driver.

Many thanks for the clarification.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #39 from Matthew Garrett (mjg59-kernel@srcf.ucam.org) ---
As noted in https://twitter.com/james_hilliard/status/1373178256615211012,
there's actually a driver here:
https://github.com/electrified/asus-wmi-sensors/ . I did a quick search
earlier, but managed to miss this somehow.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #40 from myhateisblind@hotmail.com ---
Are you sure about that driver? The github page says:

"Note: X570/B550/TRX40 boards do not have the WMI interface and are not
supported."

And those seems to be the chipsets of all or almost all boards reported in this
bug.

20 mar. 2021 8:51:07 bugzilla-daemon@bugzilla.kernel.org:

> https://bugzilla.kernel.org/show_bug.cgi?id=204807
> 
> --- Comment #39 from Matthew Garrett (mjg59-kernel@srcf.ucam.org) ---
> As noted in https://twitter.com/james_hilliard/status/1373178256615211012,
> there's actually a driver here:
> https://github.com/electrified/asus-wmi-sensors/ . I did a quick search
> earlier, but managed to miss this somehow.
> 
> -- 
> You may reply to this email to add a comment.
> 
> You are receiving this mail because:
> You are on the CC list for the bug.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #41 from Matthew Garrett (mjg59-kernel@srcf.ucam.org) ---
Interesting, it looks like it uses the same GUID but has a different set of
methods. So yes, this driver probably won't work for a bunch of the boards here
- it would need to be adapted to add support for the methods that these ones
provide.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Artem S. Tashkinov (aros@gmx.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #42 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Matthew Garrett from comment #37)
> 97845ED0-4E6D-11DE-8A39-0800200C9A66. That has an ID of 0x4243, or BC - ie,
> it's not the GUID we're looking for. The next GUID, however,
> (466747a0-70ec-11de-8a39-0800200c9a66) has an identifier of 0x4344, or BD.
> So this is the GUID we're looking for. Unfortunately asus-wmi doesn't handle
> this GUID, so new code will need to be written.
> 
> I'm going to close this bug again because it's turned into a generic bug
> covering different motherboard vendors, and there's no one size fits all
> solution. For your case the correct way to handle it is for someone to write
> a driver that uses the 466747a0-70ec-11de-8a39-0800200c9a66 interface to
> expose the sensor data. I'm afraid I don't have relevant hardware so can't
> do this myself, but please do open another bug for that.
> 
> tl;dr - the kernel message you're seeing is correct. Avoiding it requires a
> new driver to be written. If you *personally* feel safe in ignoring the
> risks, you can pass the acpi_enforce_resources=lax option, but that can't be
> the default because it's unsafe in the general case, and so it isn't the
> solution to the wider problem.

That's the problem: we have _multiple_ motherboards with _multiple_ different
chipsets from _different_ vendors 

1) all having the same glitch
2) all requiring the same workaround
3) working just fine under Windows with no hacks

> My understanding is that asus_wmi/asus_nb_wmi do the same thing as nct6775
> and expose them to hwmon class as well.

And at the same time you're talking about asus_wmi which covers only _certain_
ASUS motherboards, and no one in this discussion has shown it to work or
provide the same set of sensors.

And this driver has nothing to do with sensors,
linux/drivers/platform/x86/asus-wmi.c:

 * Asus PC WMI hotkey driver

This is not a driver which even tangentially deals with HW sensors found in
motherboards affected by this bug.

I don't know why you're trying to sweep this bug under the rug but I really
dislike it. The Linux kernel development has always followed common sense
principles and it contains a _huge_ number of workarounds just to enable HW
which doesn't work according to specs.

At the very least you could printk() this:

"Your motherboard might not exposing ACPI resources correctly, so you might not
get access to your HW sensors. You could add "acpi_enforce_resources=lax" to
kernel boot parameters to enable monitoring at your own risk. Please refer to
https://bugzilla.kernel.org/show_bug.cgi?id=204807 for more information".

And this still paints Linux in a very bad light as users hardly care about if
ACPI is implemented according to the specifications or not: however what they
really care is whether their hardware works or being supported under Linux
regardless out of the box. Most Linux users don't even know `dmesg` exists, so
they have no way of knowing how to fix the issue.

Lastly, this bug is not fixed.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #43 from Artem S. Tashkinov (aros@gmx.com) ---
A small correction of my previous comment:

linux/drivers/platform/x86/asus-nb-wmi.c

/*
 * Asus Notebooks WMI hotkey driver
 *
 * Copyright(C) 2010 Corentin Chary <corentin.chary@gmail.com>
 */

This is not related to lm-sensors in any shape or form. I'm really sad how this
situation is getting handled: the bug has been known for over 1.5 years,
affects literally hundreds of thousands devices and you're saying that this
kernel option might have unintended consequences yet _everyone_ in this thread
has enabled it with _zero_ side affects and Windows seemingly has it enabled by
default, as no such messages are getting logged in Windows Event Log either
when using HWiNFO64 or vendor specific monitoring software.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #44 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Artem S. Tashkinov from comment #42)
> "Your motherboard might not be exposing ACPI resources correctly, so you
> might
> not get access to your HW sensors. You could add
> "acpi_enforce_resources=lax" to kernel boot parameters to enable monitoring
> at your own risk. Please refer to
> https://bugzilla.kernel.org/show_bug.cgi?id=204807 for more information".

This message will at least allow various Linux distros to enable the option by
default because many are not aware of the bug.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Matthew Garrett (mjg59-kernel@srcf.ucam.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #45 from Matthew Garrett (mjg59-kernel@srcf.ucam.org) ---
Artem,

Nobody is denying there's an issue here. However, the issue is that an
additional driver needs to be written for this hardware. Please file a new bug
for that and do not keep reopening this one.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #46 from Zhang Rui (rui.zhang@intel.com) ---
(In reply to Artem S. Tashkinov from comment #43)
> A small correction of my previous comment:
> 
> linux/drivers/platform/x86/asus-nb-wmi.c
> 
> /*
>  * Asus Notebooks WMI hotkey driver
>  *
>  * Copyright(C) 2010 Corentin Chary <corentin.chary@gmail.com>
>  */
> 
> This is not related to lm-sensors in any shape or form.

asus_nb_wmi_init -> asus_wmi_register_driver -> asus_wmi_probe -> asus_wmi_add
-> asus_wmi_hwmon_init

Although the warning messages are printed by ACPI code, but this is a conflict
between the native nct6775 driver and the Asus wmi driver, because Asus wmi
driver accesses the same piece of resources and provide similar
functionalities. And I'm familiar with neither of them.

> I'm really sad how
> this situation is getting handled: the bug has been known for over 1.5
> years, affects literally hundreds of thousands devices and you're saying
> that this kernel option might have unintended consequences yet _everyone_ in
> this thread has enabled it with _zero_ side affects and Windows seemingly
> has it enabled by default, as no such messages are getting logged in Windows
> Event Log either when using HWiNFO64 or vendor specific monitoring software.

In Linux, at least for now, I don't see a way to enable native nct6775 driver
by default, and, this is true for all the native drivers that have resource
conflict with the firmware.

IMO, the rootcause is that Linux does not support override driver A (native
driver in this case) when driver B (driver that talks to firmware) is loaded,
so we have to disable driver A even if there is only 0.01% possibility that
driver B will be loaded when we know there might be a conflict.

what we can do is to write driver B to make this statement true
"ACPI: If an ACPI driver is available for this device, you should use it
instead of the native driver" and ignore this message.

(In reply to Artem S. Tashkinov from comment #44)
> (In reply to Artem S. Tashkinov from comment #42)
> > "Your motherboard might not be exposing ACPI resources correctly, so you
> > might
> > not get access to your HW sensors. You could add
> > "acpi_enforce_resources=lax" to kernel boot parameters to enable monitoring
> > at your own risk. Please refer to
> > https://bugzilla.kernel.org/show_bug.cgi?id=204807 for more information".
> 
> This message will at least allow various Linux distros to enable the option
> by default because many are not aware of the bug.

Hmmm, what about following conditions
1. "acpi_enforce_resources=" is a global switch, there might be platforms with
more than one conflict, or with another conflict rather than nct6775. we can
not validate all of them.
2. we may have new drivers that talk with firmware later, and we can not use
"acpi_enforce_resources=lax" then.

But thanks for raising this up, I think this also rings a bell that the current
message is kind of misleading.
It is true that ACPI covers a series of devices as described in the ACPI spec.
But at the same time, ACPI is an interface. Many drivers, including vendor
specific drivers, talks with firmware through the ACPI Interface. They depends
on ACPI, but they're actually not covered by the ACPI specification, nor by
kernel drivers/acpi code.

"ACPI: If an ACPI driver is available for this device, you should use it
instead of the native driver" makes people feel like it is an ACPI problem, but
in many cases, it is not, I can only triage them.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Hans de Goede (jwrdegoede@fedoraproject.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwrdegoede@fedoraproject.or
                   |                            |g

--- Comment #47 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
So if someone is willing to spend time on making this work, then here is how I
believe this could be made to work (for the case which Matthew Garrett
analysed):

1. Modify the nct6775 driver, adding a set of nct6775_register_ops to the
nct6775_sio_data struct and have any function which sits "below" the probe()
function only use these ops to do register accesses. Combined with having
sensors_nct6775_init() set these register-ops to the currently used superio
register access functions (so that nothing changes for existing users of the
driver).

2. Move the nct6775_sio_data struct declaration to a shared header somewhere
under include/linux

3. Have a new WMI driver which defines register-ops compatible with the ones
expected by the nct6775_sio_data struct, using the RHWM and WHWM methods which
Matthew found (note these should be called through their WMI wrappers) and have
this driver instantiate a platform device, with its platdata set to this new
nct6775_sio_data struct, allowing the nct6775 driver to access the registers
this way, using the mutual-exclusion mechanism build into the RHWM and WHWM
methods.

As the drivers/platform/x86 maintainer I would be more then happy to merge a
clean driver for step 3. To me this seems quite doable (to someone with some
kernel-dev experience + enough time).

Note I believe that this will not be a whole lot of work (but its not trivial
either).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #48 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
Artem,
Matthew gave a really good explanation on techical background what's going on.
What you really need is to amend existing driver(s) or provide a new one to
fulfill the functionality you want to have.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #49 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Andy Shevchenko from comment #48)
> Matthew gave a really good explanation on techical background what's going
> on. What you really need is to amend existing driver(s) or provide a new one
> to fulfill the functionality you want to have.

I'm not a programmer let alone a person who understand the innards of the Linux
kernel to even attempt to fix the issue, not to mention that:

> Note I believe that this will not be a whole lot of work (but its not trivial
> either).

Maybe we have ... kernel developers who can do that instead, for instance
lm-sensors maintainers. I don't know. I'm confused. I did my best to report the
issue. Meanwhile I'll continue to use the hack since I want to monitor my HW
right now - not a few years later when someone finally ventures to scratch the
itch. Thank you very much ;-)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #50 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
> Maybe we have ... kernel developers who can do that instead

You now kernel developers are humans too, so they need to eat and sleep and
stuff too. IOW they don't have unlimited time to spend on helping every Linux
user out there without any compensation.

Maybe you have a friend with some kernel-development experience who can help.
Or maybe you can find someone who you can pay to fix this for you?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Andy Shevchenko (andy.shevchenko@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andy.shevchenko@gmail.com

--- Comment #51 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
(In reply to Artem S. Tashkinov from comment #49)
> (In reply to Andy Shevchenko from comment #48)
> > Matthew gave a really good explanation on techical background what's going
> > on. What you really need is to amend existing driver(s) or provide a new
> one
> > to fulfill the functionality you want to have.
> 
> I'm not a programmer let alone a person who understand the innards of the
> Linux kernel to even attempt to fix the issue, not to mention that:
> 
> > Note I believe that this will not be a whole lot of work (but its not
> trivial
> > either).
> 
> Maybe we have ... kernel developers who can do that instead, for instance
> lm-sensors maintainers. I don't know. I'm confused. I did my best to report
> the issue. Meanwhile I'll continue to use the hack since I want to monitor
> my HW right now - not a few years later when someone finally ventures to
> scratch the itch. Thank you very much ;-)

Artem,
I feel your pain. Believe me, I have got into the similar situation(s) myself
being actually a kernel developer! I'm often being frustrated, but that's how
it works in Linux and in OSS in general. The root cause here is the production
model used by world of Windows and world of Linux (and besides the downsides
like above I prefer the latter). For Windows the drivers are made for *THE
product* while in *nix world the drivers try to cover as many products as they
can with regard to the similarities and compatibility of the corresponding IPs.
That's why people often see "oh, hey, it works in Windows!" Yes, it works, but
if and only if you are using the very same *THE product*. Step right or left
will be a suicidal in that model. The Windows model is very fragile because of
this and requires 10x times more resources to develop the code. OSS community
simply does not have such resources to fulfill a job and due to economical
reasons even Micro$oft also found advantages in the OSS model (but not with the
drivers, unfortunately). The best help for you and for the rest is to be on the
constructive side. You see, you even may yourself to develop a solution and
become (a well paid) kernel developer. Or just for fun (look at the example of
Intel IPU3 CIO2 camera glue layer (to support Windows only platforms) which is
done solely by one guy who declared that he even didn't know C programming
language before!

So, please, do not blame people here, it's rather the problem of the model.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Hans de Goede (jwrdegoede@fedoraproject.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwrdegoede@fedoraproject.or
                   |                            |g

--- Comment #53 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
I'm also removing myself from the Cc of this bug because the discussion here
does not seem to be productive. If anyone wants to implement the solution which
I outlined in command 47, drop me an email at hdegoede@redhat.com .

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Andy Shevchenko (andy.shevchenko@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Mateusz Jończyk (mat.jonczyk@o2.pl) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mat.jonczyk@o2.pl

--- Comment #54 from Mateusz Jończyk (mat.jonczyk@o2.pl) ---
Hello,

I was doing some preparatory work to implement the solution in comment 47 -
like analysis of source code.

Unfortunately, it seems like this solution would only work for ASUS boards. All
the acpidump outputs in this ticket are from ASUS boards. The "RHWM" and "WHWM"
methods are from an interface with UID="ASUSWMI", so they look to be
asus-specific.

For ASUS boards there exists a better driver:

https://github.com/electrified/asus-wmi-sensors

so there is probably no reason to implement direct access to nct6775.

Are there any benefits from implementing access to nct6775 as outlined above?

Greetings,

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Hans de Goede (jwrdegoede@fedoraproject.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwrdegoede@fedoraproject.or
                   |                            |g

--- Comment #55 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
(In reply to Mateusz Jończyk from comment #54)
> For ASUS boards there exists a better driver:
> 
> https://github.com/electrified/asus-wmi-sensors

Interesting I wonder why that has not been submitted upstream. I'll open an
issue at its github page for that.

> so there is probably no reason to implement direct access to nct6775.
> 
> Are there any benefits from implementing access to nct6775 as outlined above?

No, that was just meant as a possible solution for the reported problem. I
agree that using the WMI interface, which presumably is what Asus' Windows
tools use, is better.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #56 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
Hmm,

asus-wmi-sensors also is not such a great solution, it seems the WMI interface
is buggy on some boards and causes fans to stop or get stuck at max speed,
which is quite bad, see:

https://github.com/electrified/asus-wmi-sensors#known-issues

So it seems that the situation with sensors on these boards simply sucks and
Asus is to blame here. If even the "official" method of accessing the sensors
is buggy then Asus needs to get their firmware fixed and until that is done
users are better of without sensors support.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #57 from Mateusz Jończyk (mat.jonczyk@o2.pl) ---
(In reply to Hans de Goede from comment #56)
> Hmm,
> 
> asus-wmi-sensors also is not such a great solution, it seems the WMI
> interface is buggy on some boards and causes fans to stop or get stuck at
> max speed, which is quite bad, see:
> 
> https://github.com/electrified/asus-wmi-sensors#known-issues

IMHO, this could be caused by access races, not necessarily by a buggy BIOS.
The driver may simply not implement correct synchronization methods. It may be
necessary to call some ACPI / WMI methods before and after accessing the
sensors to avoid resource conflicts.

As is written in the documentation:
> The more frequently the WMI interface is polled the greater the potential for
> this to happen.

I am also not sure if the driver implements correct locking behavior
kernel-wise.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #58 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
(In reply to Mateusz Jończyk from comment #57)
> (In reply to Hans de Goede from comment #56)
> > Hmm,
> > 
> > asus-wmi-sensors also is not such a great solution, it seems the WMI
> > interface is buggy on some boards and causes fans to stop or get stuck at
> > max speed, which is quite bad, see:
> > 
> > https://github.com/electrified/asus-wmi-sensors#known-issues
> 
> IMHO, this could be caused by access races, not necessarily by a buggy BIOS.
> The driver may simply not implement correct synchronization methods. It may
> be necessary to call some ACPI / WMI methods before and after accessing the
> sensors to avoid resource conflicts.

Perhaps, but usually WMI methods take the locks which they need on entry and
release them on exit. I'm not even sure if an ACPI method (which this
ultimately is) can hold locks after it exits, I would not be surprised if all
acquired locks are automatically dropped on exit from the interpreter.

Also note that the README also states that on some motherboards the problems
are fixed in later BIOS versions, which also points to a race inside the AML
code and not a bug in the driver.

> As is written in the documentation:
> > The more frequently the WMI interface is polled the greater the potential
> for
> > this to happen.
> 
> I am also not sure if the driver implements correct locking behavior
> kernel-wise.

I did not check, but this should not matter, that may mess up the driver's
state, but the WMI code is expected to do its own locking at the AML level, to
e.g. protect against similar accesses to the super IO through the ACPI thermal
region interface.

Note I'm not claiming that this is definitely not an issue with the driver, it
could be. But I've seen a lot of very buggy AML code and I've yet to find a
single vendor which does not write very low quality AML code. It seems there is
absolutely no code-review done on the AML code and very little QA.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #59 from Mateusz Jończyk (mat.jonczyk@o2.pl) ---
The Asus X570-Plus TUF Gaming was described in this ticket as not working. It
is listed as not supported by this driver on GitHub. So there are some devices
without a working WMI interface that would benefit from the handling in comment
47.

> I agree that using the WMI interface, which presumably is what Asus' Windows
> tools use, is better.

It also does not require guessing voltage divider parameters, which makes raw
access to nct6775 not that much useful.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #60 from Kamil Dudka (kdudka@redhat.com) ---
asus-wmi-sensors was already mentioned in comment #39.  I tried it with ASUS
PRIME B360-PLUS but no device was matched by the driver.  It could have been
some user error though.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #61 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Matthew Garrett from comment #39)
> As noted in https://twitter.com/james_hilliard/status/1373178256615211012,
> there's actually a driver here:
> https://github.com/electrified/asus-wmi-sensors/ . I did a quick search
> earlier, but managed to miss this somehow.

From its description:

Note: X570/B550/TRX40 boards do not have the WMI interface and are not
supported.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #62 from Kamil Dudka (kdudka@redhat.com) ---
Yes, my board was neither listed as supported, nor as unsupported/unknown in
the mentioned README file.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #63 from Sydney Meyer (syd.meyer@gmail.com) ---
Hello all,

perhaps this is the wrong place to ask such a question, but after reading many
sites on the interwebs about the issue, i am left with the impression that most
people (me included) do not actually understand the implications introduced by
turning on/off knobs like "acpi_enforce_resources=lax". Also, i read a lot,
mostly unclear, comments about "hardware damage" and therefore would like to
ask, what is actually the recommended way to go about this with the situation
as it is now? Is this issue perhaps only relevant for manual fan control,
because with or without "acpi_enforce_resources=lax" and the nct6775 kernel
module loaded, the system appears to adjust the fan speed for the appropriate
load either way and there aren't any noticable differences between CPU temps
either. So i guess my question basically boils down to this: Is there actually
something to worry about, apart from not beeing able to see/control fan speeds?
I just have become a little worried now with all the contradictive information
out there, also read (on phoronix) about this [1] and this [2] a few weeks ago.
This is a Asus X570 Gaming-E Board with a Ryzen 5950X CPU. As a regular user,
am i going to fry my little computer by running Linux on it?

I understand that nobody will guarantee anything, of course, i just felt this
might be a good place for a qualified answer, because, obviously, i don't
understand any of this low-level stuff.

Thanks a bunch.

[1] Linux 5.11 Drops AMD Zen Voltage/Current Reporting Over Lack Of
Documentation 
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.11-Drops-k10temp-V-C
[2] AMD Ryzen 5000 Temperature Monitoring Support Sent In For Linux 5.12
https://www.phoronix.com/scan.php?page=news_item&px=Zen-3-Desktop-CPU-k10temp

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #64 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
Sydney, I understand that all the discussion can be somewhat confusing.

It should be perfectly safe to run Linux on your computer (but as you said no
there is no warranty), by default Windows also does not come with any software
to monitor the nct6775 sensors. So when installing Linux without making any
changes your computer will run the same way as with a pristine (no extra sw
installed) windows install.

Under Linux you will even be able to monitor the CPU temperature using the
CPU's builtin temp-sensors. What does not work is monitoring other
temperatures, voltages and fan-speeds. Nor controlling fan-speeds.  But
typically a modern motherboard will automatically control the CPU fan speed
based on temperature, without needing the OS to do anything; Also most users
typically use their computer for other things then to monitor the computers
temps and voltages.

Matthew rightly advises against using "acpi_enforce_resources=lax" because that
opens races between the firmware and Linux which could result in writing to
another superIO register then intended. This can definitely lead to e.g.
stopping the fans even though the CPU is running hot, which is not good but all
modern CPUs have builtin overtemp protection, so at the worst the system will
simply shutdown (1). 

Theoretically this could also lead to worse outcomes, such us changes your CPU
or RAM voltage which could damage your hardware. I am aware of at least one
semi-related case where RAM got seriously overvolted damaging both the RAM and
the CPU, this was not with a Super-IO solution though, but with I2C attached
sensor probing.

1) Repeatedly overheating your CPU to where it automatically shuts down is not
good for your CPU's health though and will likely shorten its lifetime.

TL;DR: Don't use "acpi_enforce_resources=lax", otherwise running Linux should
be safe and everything should work fine.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #66 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
Sydney, thank you for your kind words, you have put a smile on my face, so
thank you.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #67 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Hans de Goede from comment #64)
> 
> Matthew rightly advises against using "acpi_enforce_resources=lax" because
> that opens races between the firmware and Linux which could result in
> writing to another superIO register then intended. This can definitely lead
> to e.g. stopping the fans even though the CPU is running hot, which is not
> good but all modern CPUs have builtin overtemp protection, so at the worst
> the system will simply shutdown (1). 
> 

Multiple users use acpi_enforce_resources=lax and I haven't seen a single
report that it's ever broken anything.

AFAIK no one has used this hack to control fans using PWM, so that might indeed
lead to unintended consequences.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #68 from myhateisblind@hotmail.com ---
I use it for that, and had no problem... yet.

15 abr. 2021 11:27:55 bugzilla-daemon@bugzilla.kernel.org:

> https://bugzilla.kernel.org/show_bug.cgi?id=204807
> 
> --- Comment #67 from Artem S. Tashkinov (aros@gmx.com) ---
> (In reply to Hans de Goede from comment #64)
>> 
>> Matthew rightly advises against using "acpi_enforce_resources=lax" because
>> that opens races between the firmware and Linux which could result in
>> writing to another superIO register then intended. This can definitely lead
>> to e.g. stopping the fans even though the CPU is running hot, which is not
>> good but all modern CPUs have builtin overtemp protection, so at the worst
>> the system will simply shutdown (1).
>> 
> 
> Multiple users use acpi_enforce_resources=lax and I haven't seen a single
> report that it's ever broken anything.
> 
> AFAIK no one has used this hack to control fans using PWM, so that might
> indeed
> lead to unintended consequences.
> 
> -- 
> You may reply to this email to add a comment.
> 
> You are receiving this mail because:
> You are on the CC list for the bug.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #69 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
(In reply to Artem S. Tashkinov from comment #67)
> Multiple users use acpi_enforce_resources=lax and I haven't seen a single
> report that it's ever broken anything.

<sigh> Yet I have been on the receiving end of a bug-report where I had to
explain to a user that the lm_sensors sensors-detect script had overvolted his
RAM ruining both his expensive high-end RAM as well as his expensive top of the
line CPU. The user was surprisingly relaxed about all this, which I really
appreciated.

And that was while the script was not doing anything which we (the developers)
considered dangerous. But the motherboard had a funky setup causing a SMbus
*read* transaction to change the voltage.

Mucking with this stuff can be dangerous and as Matthew has explained in his
thorough analysis of the DSDT the DSDT is actually accessing the superio and if
that races with a Linux kernel access a wrong register may be read from, or
worse written to.

Using acpi_enforce_resources=lax simply is dangerous and we are not going to
change the default, period, full-stop.

I welcome further discussions here about how we can *safely* solve hwmon access
on various motherboards.

Please stop discussing acpi_enforce_resources=lax, that is not a safe option to
use and more discussion about it is not productive.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

doomwarriorx@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doomwarriorx@gmail.com

--- Comment #70 from doomwarriorx@gmail.com ---
Created attachment 296451
  --> https://bugzilla.kernel.org/attachment.cgi?id=296451&action=edit
acpidump for Pro B550-C

can confirm the issue with ASUS System Product Name/Pro B550M-C, BIOS 0214
10/22/2020

The bug still exists if asus_wmi & eeepc_wmi is blacklisted. Does the acpi_wmi
still claim the address space even if no consumer/driver is available?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Bernhard Seibold (mail@bernhard-seibold.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mail@bernhard-seibold.de

--- Comment #71 from Bernhard Seibold (mail@bernhard-seibold.de) ---
Created attachment 296529
  --> https://bugzilla.kernel.org/attachment.cgi?id=296529&action=edit
Add support for access via Asus WMI to nct6775

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #72 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
(In reply to Bernhard Seibold from comment #71)
> Created attachment 296529 [details]
> Add support for access via Asus WMI to nct6775

Nice, have you submitted this to kernel's hwmon subsystem maintainer for
inclusion into the mainline kernel ?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #73 from Bernhard Seibold (mail@bernhard-seibold.de) ---
(In reply to Hans de Goede from comment #72)
> (In reply to Bernhard Seibold from comment #71)
> > Created attachment 296529 [details]
> > Add support for access via Asus WMI to nct6775
> 
> Nice, have you submitted this to kernel's hwmon subsystem maintainer for
> inclusion into the mainline kernel ?

No, I just finished writing this. I cannot test if it still works correctly for
non-WMI cases, and I think using device address zero for WMI is probably a bit
hackish.

Please also note that this patch only adds access via WMI for i/o port 0x295,
while superio access is still using the "traditional" method. There are however
also WMI methods for superio access, at least on my board, and it would
probably be safer to use those as well. However I would propose to first split
the superio functionality into a separate driver. Comments in nct6775 seem to
imply that this was/is intended to be done at some point.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #74 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
> Please also note that this patch only adds access via WMI for i/o port 0x295,
> while superio access is still using the "traditional" method.

Ah I missed that, yes that needs to be resolved before this is suitable for
upstream. Thank you for your work on this.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Bernhard Seibold (mail@bernhard-seibold.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #296529|0                           |1
        is obsolete|                            |

--- Comment #75 from Bernhard Seibold (mail@bernhard-seibold.de) ---
Created attachment 296645
  --> https://bugzilla.kernel.org/attachment.cgi?id=296645&action=edit
Add support for access via Asus WMI to nct6775 (Rev 2)

Here's an updated patch that also accesses the Super-I/O ports via WMI. Please
note that it also adds an ACPI resource check for that IO region. So it might
actually make the driver work on less hardware, although that check should
probably have been there in the first place.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #76 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Bernhard Seibold from comment #75)
> Created attachment 296645 [details]
> Add support for access via Asus WMI to nct6775 (Rev 2)
> 
> Here's an updated patch that also accesses the Super-I/O ports via WMI.
> Please note that it also adds an ACPI resource check for that IO region. So
> it might actually make the driver work on less hardware, although that check
> should probably have been there in the first place.

Seems to work here, thank you very much!

nct6775: Found NCT6798D or compatible chip at 0x0:0x290
nct6775: Using Asus WMI to access chip

$ sensors

nct6798-isa-0000
Adapter: ISA adapter

I'm only curious why it continues to say ISA adapter which doesn't seem
technically correct.

Anyways, please submit for Linux 5.13 - it mustn't be too late as we are now in
a merge window.

Tested-by: Artem S. Tashkinov <aros@gmx.com>

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Vittorio Roberto Alfieri (me@rebtoor.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |me@rebtoor.com

--- Comment #77 from Vittorio Roberto Alfieri (me@rebtoor.com) ---
(In reply to Bernhard Seibold from comment #75)
> Created attachment 296645 [details]
> Add support for access via Asus WMI to nct6775 (Rev 2)
> 
> Here's an updated patch that also accesses the Super-I/O ports via WMI.
> Please note that it also adds an ACPI resource check for that IO region. So
> it might actually make the driver work on less hardware, although that check
> should probably have been there in the first place.

Hi,
I can confirm that this patch works for me too. 

dmesg |grep nct6775
[   43.723698] nct6775: Found NCT6798D or compatible chip at 0x0:0x290
[   43.723890] nct6775: Using Asus WMI to access chip

sensors nct6798-* | head -2
nct6798-isa-0000
Adapter: ISA adapter

mobo: ASUS ROG STRIX B550-F GAMING (WI-FI) - bios version 2403
kernel: 5.13.0 (patched)

Thanks Bernhard!

Have a nice sunday everyone.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #79 from Bernhard Seibold (mail@bernhard-seibold.de) ---
(In reply to Gregory Duhamel from comment #78)
> Is there any chance this patch reach upstream ? Thanks a lot Guys !

I submitted the patch, but it was rejected and I don't intend to continue
working on it, sorry.

https://www.spinics.net/lists/linux-hwmon/msg11260.html

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Artem S. Tashkinov (aros@gmx.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |REOPENED
         Resolution|INVALID                     |---

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Andy Shevchenko (andy.shevchenko@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |PATCH_ALREADY_AVAILABLE

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #80 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
(In reply to Bernhard Seibold from comment #79)
> (In reply to Gregory Duhamel from comment #78)
> > Is there any chance this patch reach upstream ? Thanks a lot Guys !
> 
> I submitted the patch, but it was rejected and I don't intend to continue
> working on it, sorry.
> 
> https://www.spinics.net/lists/linux-hwmon/msg11260.html

To be honest I have no evidence it was rejected, rather additional work is
needed. This is standard practice in OSS projects, especially big ones like
kernel to reshape patch(es) a few times when it will satisfy all parties.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

danglingpointerexception@gmail.com (danglingpointerexception@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglingpointerexception@gm
                   |                            |ail.com

--- Comment #81 from danglingpointerexception@gmail.com (danglingpointerexception@gmail.com) ---
Hi All, I've got the same issue with a ASUS ROG STRIX X570-E Gaming.

We need this patch merged!  Can anyone with influence or clout help push this
along so we can get this resolved?

There must be hundreds of thousands affected by this!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Andy Shevchenko (andy.shevchenko@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|torvalds@linux-foundation.o |
                   |rg                          |

--- Comment #82 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
(In reply to danglingpointerexception@gmail.com from comment #81)
> Hi All, I've got the same issue with a ASUS ROG STRIX X570-E Gaming.
> 
> We need this patch merged!  Can anyone with influence or clout help push
> this along so we can get this resolved?
> 
> There must be hundreds of thousands affected by this!

The best what you can do is to go to the mailing list and discuss it there with
a respective maintainer.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #83 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Andy Shevchenko from comment #82)
> 
> The best what you can do is to go to the mailing list and discuss it there
> with a respective maintainer.

Meanwhile this bug is not resolved and there's no (accepted) patch. The bug
status is wrong and misleading but I'm not going to argue :-)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #84 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
(In reply to Artem S. Tashkinov from comment #83)
> (In reply to Andy Shevchenko from comment #82)
> > 
> > The best what you can do is to go to the mailing list and discuss it there
> > with a respective maintainer.
> 
> Meanwhile this bug is not resolved and there's no (accepted) patch. The bug
> status is wrong and misleading but I'm not going to argue :-)

First of all, read comment #80, second, do not misinterpret the bug status. It
shows exactly the current state of affairs. If nobody wants to work further on
the offered change, it's not a problem of the community. Linux kernel does not
work on "take it or leave it" terms. So, instead of whining here, roll up your
sleeves and finish the job, that would be much better!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pauk.denis@gmail.com

--- Comment #85 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 298539
  --> https://bugzilla.kernel.org/attachment.cgi?id=298539&action=edit
POC: Add support for access via Asus WMI to nct6775 by board name detect

I have added only small list of board names(/sys/class/dmi/id/board_name),
could you add yours and check?

P.S.: I have not checked with real devices.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #86 from Tom Lloyd (napalmllama@gmail.com) ---
Please add my board name "TUF GAMING B550-PLUS".

I'm happy to roll the patch into my kernel and make whatever checks are needed,
but I'm new to this so could use some guidance.  Email me if you want me to
test on my box?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

to.eivind@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |to.eivind@gmail.com

--- Comment #87 from to.eivind@gmail.com ---
(In reply to Denis Pauk from comment #85)
> Created attachment 298539 [details]
> POC: Add support for access via Asus WMI to nct6775 by board name detect
> 
> I have added only small list of board names(/sys/class/dmi/id/board_name),
> could you add yours and check?
> 
> P.S.: I have not checked with real devices.

Thank you all for your great work.

I added my board "ROG STRIX B550-F GAMING (WI-FI)" and added patch against
5.14.1-arch1-1 BIOS 2423 08/10/2021.

$ dmesg | grep nct6775
[    6.878846] nct6775: Found NCT6798D or compatible chip at 0x0:0x290
[    6.879018] nct6775: Using Asus WMI to access chip

$ sensors
nct6798-isa-0000
Adapter: ISA adapter
in0:                      472.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.33 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      960.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      280.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.36 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.33 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      904.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     304.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                       1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     408.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     304.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                      714 RPM  (min =    0 RPM)
fan2:                      776 RPM  (min =    0 RPM)
fan3:                      708 RPM  (min =    0 RPM)
fan4:                      870 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +28.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +35.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +82.5°C    sensor = thermistor
AUXTIN1:                   +49.0°C    sensor = thermistor
AUXTIN2:                   -60.0°C    sensor = thermistor
AUXTIN3:                   +78.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +35.5°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled


Would be very, very nice if someone has the knowledge to make this acceptable
for upstream.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #298539|0                           |1
        is obsolete|                            |

--- Comment #88 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 298669
  --> https://bugzilla.kernel.org/attachment.cgi?id=298669&action=edit
POC: Add support for access via Asus WMI to nct6775 by board/vendor name detect

Updated version with check vendor name and fix for possible issues with non
ASUS motherboards, added names of motherboards have mentioned in bug. I will
also check possible way for use functions pointers instead conditional checks
equal to access_wmi. After that I will try to send patch to review.

(In reply to comment #87)
> I added my board "ROG STRIX B550-F GAMING (WI-FI)" and added patch against
> 5.14.1-arch1-1 BIOS 2423 08/10/2021.

Thank you, I have added your board also.

(In reply to comment #86)
> Please add my board name "TUF GAMING B550-PLUS".

Thank you, I have added it to list. What the distro do you use? 

For debian it can be:
* git clone
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
* cd linux-stable
* git check v5.14
* cp /boot/config-5.10.0-8-amd64 .config
* make CC="ccache gcc" -j 32
* make CC="ccache gcc" -j 32 bindeb-pkg
* sudo dpkg -i ../linux-image-5.14.0+_5.14.0+-1_amd64.deb

Look to https://wiki.debian.org/BuildADebianKernelPackage

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Barnabás Pőcze (pobrn@protonmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pobrn@protonmail.com

--- Comment #89 from Barnabás Pőcze (pobrn@protonmail.com) ---
As a side note: using dkms is much faster than recompiling the whole kernel.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

pehlm@pekholm.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pehlm@pekholm.org

--- Comment #90 from pehlm@pekholm.org ---
Can you please also add my board: "TUF GAMING X570-PLUS".

Thank you for working on the patch!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #91 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to pehlm from comment #90)
> Can you please also add my board: "TUF GAMING X570-PLUS".
> 
> Thank you for working on the patch!

I'm pretty sure all X570 based ASUS motherboards with this chip have to work
via WMI and adding them one by one will needlessly inflate the patch.
Blacklisting could be used instead (though I'm quite sure there will be no SKUs
to blacklist).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #92 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
(In reply to Artem S. Tashkinov from comment #91)
> (In reply to pehlm from comment #90)
> > Can you please also add my board: "TUF GAMING X570-PLUS".
> > 
> > Thank you for working on the patch!
> 
> I'm pretty sure all X570 based ASUS motherboards with this chip have to work
> via WMI and adding them one by one will needlessly inflate the patch.
> Blacklisting could be used instead (though I'm quite sure there will be no
> SKUs to blacklist).

I even might agree with you, but here is a dilemma: do you want to have the
patch accepted in mainline (*), or do you want a better code right now?

*) this is what maintainer wants.

@Denis Pauk, you may consider to have an array of strings and use
match_string() call instead of plenty of strcmp():s.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #298669|0                           |1
        is obsolete|                            |

--- Comment #93 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 298703
  --> https://bugzilla.kernel.org/attachment.cgi?id=298703&action=edit
POC: Add support for access via Asus WMI to nct6775 use match_string

* Use match_string for filter boards
* use function pointers for superio

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #94 from dflogeras2@gmail.com ---
Thanks Denis!  Can confirm the module loads successfully on an Asus PRIME
B460-PLUS with the following:

[608513.608260] acpi PNP0C14:02: duplicate WMI GUID
05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
[608513.608293] acpi PNP0C14:03: duplicate WMI GUID
05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
[608513.608355] acpi PNP0C14:04: duplicate WMI GUID
05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
[608513.608404] acpi PNP0C14:05: duplicate WMI GUID
05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
[608513.609331] nct6775: Using Asus WMI to access chip
[608513.609437] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290

I'm not sure about the duplicate warnings, maybe because I am still running a
kernel with acpi_enforce_resources=lax (did not reboot before inserting the
patched module).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #95 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to dflogeras2 from comment #94)
> Thanks Denis!  Can confirm the module loads successfully on an Asus PRIME
> B460-PLUS with the following:
> 
> [608513.608260] acpi PNP0C14:02: duplicate WMI GUID
> 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
> [608513.608293] acpi PNP0C14:03: duplicate WMI GUID
> 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
> [608513.608355] acpi PNP0C14:04: duplicate WMI GUID
> 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
> [608513.608404] acpi PNP0C14:05: duplicate WMI GUID
> 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
> [608513.609331] nct6775: Using Asus WMI to access chip
> [608513.609437] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
> 
> I'm not sure about the duplicate warnings, maybe because I am still running
> a kernel with acpi_enforce_resources=lax (did not reboot before inserting
> the patched module).

That's bug 201885 which is not related to this one.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #96 from Tom Lloyd (napalmllama@gmail.com) ---
(In reply to Denis Pauk from comment #88)
> Created attachment 298669 [details]
> POC: Add support for access via Asus WMI to nct6775 by board/vendor name
> detect
> 
> Updated version with check vendor name and fix for possible issues with non
> ASUS motherboards, added names of motherboards have mentioned in bug. I will
> also check possible way for use functions pointers instead conditional
> checks equal to access_wmi. After that I will try to send patch to review.
> 
> (In reply to comment #87)
> > I added my board "ROG STRIX B550-F GAMING (WI-FI)" and added patch against
> > 5.14.1-arch1-1 BIOS 2423 08/10/2021.
> 
> Thank you, I have added your board also.
> 
> (In reply to comment #86)
> > Please add my board name "TUF GAMING B550-PLUS".
> 
> Thank you, I have added it to list. What the distro do you use? 
> 
> For debian it can be:
> * git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> * cd linux-stable
> * git check v5.14
> * cp /boot/config-5.10.0-8-amd64 .config
> * make CC="ccache gcc" -j 32
> * make CC="ccache gcc" -j 32 bindeb-pkg
> * sudo dpkg -i ../linux-image-5.14.0+_5.14.0+-1_amd64.deb
> 
> Look to https://wiki.debian.org/BuildADebianKernelPackage

Denis,

I'm on Gentoo, and already have the kernel sources unpacked and ready to go
(5.13.13-gentoo).  I did the following:

# rmmod nct6775
# cd /usrc/src/linux
# patch -i ~/nct6775_wmi_v3.patch -p1
# make modules -j12
# mv
/lib/modules/5.13.13-gentoo-splig-3-sensors/kernel/drivers/hwmon/nct6775.ko
/lib/modules/5.13.13-gentoo-splig-3-sensors/kernel/drivers/hwmon/nct6775.ko.orig
# cp drivers/hwmon/nct6775.ko
/lib/modules/5.13.13-gentoo-splig-3-sensors/kernel/drivers/hwmon/nct6775.ko
# modprobe nct6775

"sensors" output remains the same:
nct6798-isa-0290
Adapter: ISA adapter
in0:                      376.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.30 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                        1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      880.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      256.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.28 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      904.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     264.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                       1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.04 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     368.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     272.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                        0 RPM  (min =    0 RPM)
fan2:                      716 RPM  (min =    0 RPM)
fan3:                      496 RPM  (min =    0 RPM)
fan4:                      327 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +33.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +35.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +85.0°C    sensor = thermistor
AUXTIN1:                   +55.0°C    sensor = thermistor
AUXTIN2:                   -61.0°C    sensor = thermistor
AUXTIN3:                   +79.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +34.5°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

dmesg with tree module:
[ 3596.867638] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[ 3596.867642] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210331/utaddress-204)
[ 3596.867645] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[ 3596.867646] ACPI: OSL: Resource conflict: System may be unstable or behave
erratically

dmesg with patched module:
[ 3681.885428] nct6775: Using Asus WMI to access chip
[ 3681.885468] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290

/proc/cmdline:
BOOT_IMAGE=/boot/vmlinuz-5.13.13-gentoo-splig-3-sensors root=/dev/nvme0n1p3 ro
module_blacklist=nouveau acpi_enforce_resources=lax


I hope that's of some use.  The differing dmesg output suggests that the patch
is helping, but shouldn't there be a change (improvement) to the sensors
output?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #98 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Tom Lloyd from comment #96)
> 
> I hope that's of some use.  The differing dmesg output suggests that the
> patch is helping, but shouldn't there be a change (improvement) to the
> sensors output?

The patch which is being worked on here is simply changing the method of
accessing hardware, it does _not_ change the underlying driver which deciphers
the sensor inputs. 

To improve the output you've got to create e.g. /etc/sensors.d/nct6798.conf and
describe your desired configuration there but that's outside the scope of this
bugzilla. Please read lm-sensors documentations for that.

I've already done that for the ASUS TUF GAMING X570-PLUS (WI-FI) motherboard:
https://github.com/lm-sensors/lm-sensors/pull/216 but my configuration is very
incomplete since the documentation for this chip is likely proprietary and not
available publicly. Even HWiNFO64 fails to decipher multiple inputs and shows
them as is and that's the best application for that under Windows. Then certain
inputs may simply not be connected to anything and basically report white
noise.

If you have close contacts at ASUS they may give you the data but that's far
from certain. For some reasons hardware monitoring for motherboards, GPUs and
CPUs is veiled in secrecy and protected by patents and NDA.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #99 from Tom Lloyd (napalmllama@gmail.com) ---
That all makes sense, thanks both for the clarification.  I can confirm then
that the patch works on my hardware "TUF GAMING B550-PLUS".  Good luck getting
it into the tree :)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Sahan Fernando (sahan.h.fernando@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sahan.h.fernando@gmail.com

--- Comment #101 from Sahan Fernando (sahan.h.fernando@gmail.com) ---
```
$ sudo dmidecode   | grep -i B550
        Product Name: ROG STRIX B550-F GAMING
$
```

The patch worked for me after adding my board name, could you please also add
"ROG STRIX B550-F GAMING"?

Thank you for working on this patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #103 from Jonathan (greenbigfrog@gmail.com) ---
Hi,
(oh. Could've put my comment in the attachment comment... duh)
I applied Denis Pauk patch today, (how I did it described in
https://gist.github.com/greenbigfrog/26f948c9d86f1cb2fd23bfeaa23ca068 ). While
I'm not sure if I did everything correctly, I can see nct6775 pulling in the
wmi module now, so I'm fairly certain I'm running the patch.
And yet I'm somehow still getting the acpi access warning, and no further
sensor output.
Did I do something wrong?

System: Asus TUF Gaming X570-Plus (Wi-Fi) with 5600X

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Igor (igor@svelig.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |igor@svelig.com

--- Comment #104 from Igor (igor@svelig.com) ---
Hi guys,

I have tried the patch for my "ROG STRIX B550-I GAMING", LGFM:
```
nct6798-isa-0290
Adapter: ISA adapter
Vcore:                    472.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                        1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
AVSB:                       3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
3VCC:                       3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
+12V:                      12.19 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      856.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
+5V:                        1.48 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
3.3V:                       3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
Vbat:                       3.47 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      896.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     280.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     280.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                      750 RPM  (min =    0 RPM)
CPU Fan:                   585 RPM  (min =    0 RPM)
CHA_FAN1:                    0 RPM  (min =    0 RPM)
SYSTIN:                    +34.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +33.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +80.5°C    sensor = thermistor
AUXTIN1:                   +34.0°C    sensor = thermistor
AUXTIN2:                   +34.0°C    sensor = thermistor
AUXTIN3:                   +86.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +33.0°C  
beep_enable:              disabled
```

The TUF-GAMING-X570-PLUS.conf config file was used from the comment 98.
Just wonder, so high temperature on AUXTIN0 and on AUXTIN3 is something real?
And what it could be? Or it could be because the TUF-GAMING-X570-PLUS.conf is
badly applicable/adjusted for another MB model?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #105 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Jonathan from comment #103)
> Hi,
> (oh. Could've put my comment in the attachment comment... duh)
> I applied Denis Pauk patch today, (how I did it described in
> https://gist.github.com/greenbigfrog/26f948c9d86f1cb2fd23bfeaa23ca068 ).
> While I'm not sure if I did everything correctly, I can see nct6775 pulling
> in the wmi module now, so I'm fairly certain I'm running the patch.
> And yet I'm somehow still getting the acpi access warning, and no further
> sensor output.
> Did I do something wrong?
> 
> System: Asus TUF Gaming X570-Plus (Wi-Fi) with 5600X

Could you please check with original patch from Bernhard Seibold?
And check what is value in "/sys/class/dmi/id/board_name" ?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #106 from Jonathan (greenbigfrog@gmail.com) ---
(In reply to Denis Pauk from comment #105)
> (In reply to Jonathan from comment #103)
> > Hi,
> > (oh. Could've put my comment in the attachment comment... duh)
> > I applied Denis Pauk patch today, (how I did it described in
> > https://gist.github.com/greenbigfrog/26f948c9d86f1cb2fd23bfeaa23ca068 ).
> > While I'm not sure if I did everything correctly, I can see nct6775 pulling
> > in the wmi module now, so I'm fairly certain I'm running the patch.
> > And yet I'm somehow still getting the acpi access warning, and no further
> > sensor output.
> > Did I do something wrong?
> > 
> > System: Asus TUF Gaming X570-Plus (Wi-Fi) with 5600X
> 
> Could you please check with original patch from Bernhard Seibold?
> And check what is value in "/sys/class/dmi/id/board_name" ?

Sure. I'll try the "original" patch tomorrow.

```
cat /sys/class/dmi/id/board_name                                                
TUF GAMING X570-PLUS (WI-FI)
```

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Damir Perisa (damir.perisa@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |damir.perisa@gmail.com

--- Comment #108 from Damir Perisa (damir.perisa@gmail.com) ---
i can confirm for "ROG CROSSHAIR VIII DARK HERO" (Rev X.0x):

[    3.360424] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[    3.360433] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210604/utaddress-204)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #109 from Jonathan (greenbigfrog@gmail.com) ---
Created attachment 298799
  --> https://bugzilla.kernel.org/attachment.cgi?id=298799&action=edit
dmesg for boot with Denis's patch applied

(In reply to Jonathan from comment #106)
> (In reply to Denis Pauk from comment #105)
> > (In reply to Jonathan from comment #103)
> > > Hi,
> > > (oh. Could've put my comment in the attachment comment... duh)
> > > I applied Denis Pauk patch today, (how I did it described in
> > > https://gist.github.com/greenbigfrog/26f948c9d86f1cb2fd23bfeaa23ca068 ).
> > > While I'm not sure if I did everything correctly, I can see nct6775
> pulling
> > > in the wmi module now, so I'm fairly certain I'm running the patch.
> > > And yet I'm somehow still getting the acpi access warning, and no further
> > > sensor output.
> > > Did I do something wrong?
> > > 
> > > System: Asus TUF Gaming X570-Plus (Wi-Fi) with 5600X
> > 
> > Could you please check with original patch from Bernhard Seibold?
> > And check what is value in "/sys/class/dmi/id/board_name" ?
> 
> Sure. I'll try the "original" patch tomorrow.
> 
> ```
> cat /sys/class/dmi/id/board_name                                            
> 
> TUF GAMING X570-PLUS (WI-FI)
> ```

I've tested both patches now. I had trouble getting Bernhard's to run via dkms,
so I built a custom kernel. Worked flawlessly afterwards.
Out of fairness (since I'm really not that sure if my dkms attempts yesterday
actually worked), I also built a kernel with Denis's patch. Didn't change much.
I've attached dmesg for Denis's patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #298703|0                           |1
        is obsolete|                            |

--- Comment #110 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 298805
  --> https://bugzilla.kernel.org/attachment.cgi?id=298805&action=edit
POC: Add support for access via Asus WMI to nct6775 with debug

Add more debug information about what is wrong with match vendor/board names.

(In reply to Jonathan from comment #109)
> Created attachment 298799 [details]
> dmesg for boot with Denis's patch applied

Could you add your board to list and recheck?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #111 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
Most of these boards, as you probably know already, seem to not provide
readings for all the available sensors via the Nuvoton chip. For example, water
temperature sensors are unavailable. Readings from those sensors are available
via the embedded controller registers. Thus I created a little HWMON driver [1]
to read them using WMI method 'BREC' (probably stands for Block Read Embedded
Controller). The driver currently supports only three boards (ROG Crosshair
VIII Hero, ROG Crosshair VIII Dark Hero, ROG STRIX X570-E GAMING). ROG
Crosshair VIII Formula should not differ, but need someone with the hardware to
test.

While working on these sensors for the Libre Hardware Monitor project, we found
that the Nuvoton 6798D chip provides sensors readings for configured in the
BIOS QFan sources in its registers [2]. Maybe those are worth displaying with
the nct6775 driver? They can include sensors that are otherwise are available
from the embedded controller only.

If you want to add support for your boards, feel free to submit patches to
either project (and notify me to update the driver for HWMON from LHM if
needed, please).

[1] https://github.com/zeule/asus-wmi-ec-sensors
[2] https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/issues/533

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #112 from sefoci9222@rerunway.com ---

please add:


cat /sys/class/dmi/id/board_name

ROG STRIX X570-F GAMING


can confirm latest debug.diff is working, many thanks:


Now follows a summary of the probes I have just done.
Just press ENTER to continue: 

Driver `nct6775':
  * ISA bus, address 0x290
    Chip `Nuvoton NCT6798D Super IO Sensors' (confidence: 9)

Driver `k10temp' (autoloaded):
  * Chip `AMD Family 17h thermal sensors' (confidence: 9)

Do you want to overwrite /etc/sysconfig/lm_sensors? (YES/no): 
Unloading i2c-dev... OK

-

Sep 15 01:55:35 desk kernel: nct6775: Using Asus WMI to access 0xc1 chip.
Sep 15 01:55:35 desk kernel: nct6775: Found NCT6798D or compatible chip at
0x2e:0x290

Sep 15 02:02:41 desk systemd[1]: Starting Hardware Monitoring Sensors...
Sep 15 02:02:41 desk kernel: nct6775: Using Asus WMI to access 0xc1 chip.
Sep 15 02:02:41 desk kernel: nct6775: Found NCT6798D or compatible chip at
0x2e:0x290
Sep 15 02:02:41 desk systemd[1]: Finished Hardware Monitoring Sensors.

-

[root@desk testM]# sensors
amdgpu-pci-0700
Adapter: PCI adapter
vddgfx:      950.00 mV 
fan1:         835 RPM  (min =    0 RPM, max = 3200 RPM)
edge:         +39.0°C  (crit = +91.0°C, hyst = -273.1°C)
power1:       44.15 W  (cap = 277.00 W)

nct6798-isa-0290
Adapter: ISA adapter
in0:                      888.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                      992.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.30 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                        1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      960.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      256.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.33 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      904.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     480.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     496.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     344.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     256.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                      678 RPM  (min =    0 RPM)
fan2:                      575 RPM  (min =    0 RPM)
fan3:                     1050 RPM  (min =    0 RPM)
fan4:                      738 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +28.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +33.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +86.0°C    sensor = thermistor
AUXTIN1:                   +28.0°C    sensor = thermistor
AUXTIN2:                   +26.0°C    sensor = thermistor
AUXTIN3:                   +91.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +33.5°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +32.6°C  
Tdie:         +32.6°C  
Tccd1:        +39.5°C

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #113 from Jonathan (greenbigfrog@gmail.com) ---
(In reply to Denis Pauk from comment #110)
> Created attachment 298805 [details]
> POC: Add support for access via Asus WMI to nct6775 with debug
> 
> Add more debug information about what is wrong with match vendor/board names.
> 
> (In reply to Jonathan from comment #109)
> > Created attachment 298799 [details]
> > dmesg for boot with Denis's patch applied
> 
> Could you add your board to list and recheck?

This patch works, after adding "TUF GAMING X570-PLUS (WI-FI)".
(At first it didn't, but then I noticed I did forget the closing bracket on
"(WI-FI")

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #114 from Denis Pauk (pauk.denis@gmail.com) ---
Patch series are applied by Guenter Roeck. https://lkml.org/lkml/2021/9/17/1079

Thank you everyone!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #116 from Pär Ekholm (pehlm@pekholm.org) ---
Thank you very much for your work, Denis!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

matt-testalltheway (sefoci9222@rerunway.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sefoci9222@rerunway.com

--- Comment #117 from matt-testalltheway (sefoci9222@rerunway.com) ---
(In reply to Denis Pauk from comment #114)
> Patch series are applied by Guenter Roeck.
> https://lkml.org/lkml/2021/9/17/1079
> 
> Thank you everyone!

guess i was a bit late to the party and "ROG STRIX X570-F GAMING" did not get
added (as per comment 112).. but hey thanks for this patch :)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #118 from Kamil Dudka (kdudka@redhat.com) ---
Thanks!  I confirm the patch works for me with ASUS PRIME B360-PLUS and
linux-5.14.5 after adding the board on the white-list:

--- a/drivers/hwmon/nct6775.c
+++ b/drivers/hwmon/nct6775.c
@@ -4986,6 +4986,7 @@ static int __init nct6775_find(int sioaddr, struct
nct6775_sio_data *sio_data)
 static struct platform_device *pdev[2];

 static const char * const asus_wmi_boards[] = {
+   "PRIME B360-PLUS",
    "PRIME B460-PLUS",
    "ROG CROSSHAIR VIII DARK HERO",
    "ROG CROSSHAIR VIII HERO",


# sensors nct6796-isa-0290
nct6796-isa-0290
Adapter: ISA adapter
Vcore:                    376.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                        1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
AVCC:                       3.46 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
+3.3V:                      3.42 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                        1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      144.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      120.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
3VSB:                       3.46 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
Vbat:                       3.22 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                        1.05 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     152.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     128.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                     136.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     120.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     136.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                     1073 RPM  (min =    0 RPM)
fan2:                     1214 RPM  (min =    0 RPM)
fan3:                        0 RPM  (min =    0 RPM)
fan4:                        0 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +28.0°C  (high = +98.0°C, hyst = +95.0°C)  sensor =
thermistor
CPUTIN:                    +33.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                  +111.0°C    sensor = thermistor
AUXTIN1:                  +118.0°C    sensor = thermistor
AUXTIN2:                  +117.0°C    sensor = thermistor
AUXTIN3:                  +118.0°C    sensor = thermistor
PECI Agent 0:              +37.0°C  (high = +98.0°C, hyst = +95.0°C)
                                    (crit = +100.0°C)
PECI Agent 0 Calibration:  +32.0°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

nutodafozo@freeweb.email changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nutodafozo@freeweb.email

--- Comment #119 from nutodafozo@freeweb.email ---
does this patch change how kernel reads the sensor values (e.g. to that buggy
asus wmi interface) or it merely sets specifically for nct67 module what
"acpi_enforce_resources=lax" does?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #120 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to nutodafozo from comment #119)
> does this patch change how kernel reads the sensor values (e.g. to that
> buggy asus wmi interface) or

The underlying module/driver which reads sensors data is the same and this
patch doesn't touch it.

> it merely sets specifically for nct67 module what
> "acpi_enforce_resources=lax" does?

Exactly.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Robert Swiecki (robert@swiecki.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robert@swiecki.net

--- Comment #121 from Robert Swiecki (robert@swiecki.net) ---
FYI, tested also with "ROG CROSSHAIR VIII FORMULA", works well.

[72758.077595] nct6775: Using Asus WMI to access chip
[72758.077637] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290

nct6798-isa-0290
Adapter: ISA adapter
in0:                      936.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                        1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.31 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                        1.74 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      592.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                        1.08 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.31 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      912.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                      80.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                      96.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                       1.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     904.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                      422 RPM  (min =    0 RPM)
fan2:                      991 RPM  (min =    0 RPM)
fan3:                        0 RPM  (min =    0 RPM)
fan4:                        0 RPM  (min =    0 RPM)
fan5:                      626 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +35.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +38.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +22.0°C    sensor = thermistor
AUXTIN1:                  +104.0°C    sensor = thermistor
AUXTIN2:                   +98.0°C    sensor = thermistor
AUXTIN3:                   +31.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +39.0°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Kamil Pietrzak (kpietrzak@disroot.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kpietrzak@disroot.org

--- Comment #122 from Kamil Pietrzak (kpietrzak@disroot.org) ---
I confrm patch works on my "TUF GAMING Z490-PLUS (WI-FI)".

[1295150.017048] nct6775: Found NCT6798D or compatible chip at 0x0:0x290

nct6798-isa-0000
Adapter: ISA adapter
in0:                      835.00 mV (min =  +0.00 V, max =  +1.94 V)
in1:                        5.00 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.33 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                       12.00 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      784.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.12 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                        1.06 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                       1.36 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     960.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.04 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                       1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                      369 RPM  (min =    0 RPM)
fan2:                      389 RPM  (min =    0 RPM)
fan3:                      398 RPM  (min =    0 RPM)
fan4:                        0 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +30.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +33.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +26.0°C    sensor = thermistor
AUXTIN1:                    +7.0°C    sensor = thermistor
AUXTIN2:                   +28.0°C    sensor = thermistor
AUXTIN3:                   +25.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +32.5°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
intrusion0:               OK
intrusion1:               ALARM
beep_enable:              disabled


I also noticed that some voltage values reported by nct6775 differs from the
ones reported by Asus software on Windows.

I changed voltage scaling factors to those listed below and now voltages are
reported like on Asus software on Windows.

/*
 * Some of the voltage inputs have internal scaling, the tables below
 * contain 8 (the ADC LSB in mV) * scaling factor * 100
 */
static const u16 scale_in[15] = {
        888, 4000, 1600, 1600, 9600, 800, 800, 1600, 1600, 1600, 1600, 1600,
800,
        800, 800
};

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #123 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Kamil Pietrzak from comment #122)
> I confrm patch works on my "TUF GAMING Z490-PLUS (WI-FI)".
> 
> [1295150.017048] nct6775: Found NCT6798D or compatible chip at 0x0:0x290
....
> 
> I also noticed that some voltage values reported by nct6775 differs from the
> ones reported by Asus software on Windows.
> 
> I changed voltage scaling factors to those listed below and now voltages are
> reported like on Asus software on Windows.
> 
> /*
>  * Some of the voltage inputs have internal scaling, the tables below
>  * contain 8 (the ADC LSB in mV) * scaling factor * 100
>  */
> static const u16 scale_in[15] = {
>       888, 4000, 1600, 1600, 9600, 800, 800, 1600, 1600, 1600, 1600, 1600,
> 800,
>       800, 800
> };

It looks like need to update code with custom scale values in relation to board
name. And it can be in future patches. 

Also need to look what functionality is nondestructive and can be merged in:
* https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/OpenRGB.patch
*
https://github.com/zeule/asus-wmi-ec-sensors/blob/master/asus-wmi-ec-sensors.c
* https://github.com/electrified/asus-wmi-sensors/
and cover maximum boards.

OpenRGB looks as good candidate for merge, as I see it uses i2c bus instead
asuswmi, and we already have ground for custom logic, it should be possible if
we have list of boards where such access is implemented by ASUS?.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

mirh (mirh@protonmail.ch) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chunkeey@googlemail.com,
                   |                            |mirh@protonmail.ch

--- Comment #124 from mirh (mirh@protonmail.ch) ---
(In reply to Eugene Shalygin from comment #111)
> Most of these boards, as you probably know already, seem to not provide
> readings for all the available sensors via the Nuvoton chip. For example, 
> [...] we found that the Nuvoton 6798D chip provides sensors readings for
> configured in the BIOS QFan sources in its registers [2]. Maybe those are
> worth displaying with the nct6775 driver? They can include sensors that
> are otherwise are available from the embedded controller only.

I can't really vouch for high end desktop motherboards, but at least as far as
laptops are concerned this has been the case since forever about everywhere
(ranging from "somewhat nitpicky" lacks to "kinda important" ones)
https://github.com/daringer/asus-fan/issues/13
https://github.com/daringer/asus-fan/issues/44#issuecomment-487380638

I don't know how dangerous accessing EC could be (be it directly, or through
possible ACPI methods.. in some cases datasheets may even be available), but
something else that isn't just vanilla WMI is needed. 

https://sourceforge.net/p/acpi4asus/mailman/message/7375427/
Btw following the breadcrumb trail of the asus linux drivers history.. it seems
like different/older machines may have used 'ECRW' in its place (or if not any
I found that to still be present on my 2016 X756UX).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #298805|0                           |1
        is obsolete|                            |

--- Comment #125 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 298887
  --> https://bugzilla.kernel.org/attachment.cgi?id=298887&action=edit
Add support for access via Asus WMI to nct6775 (2021.09.20)

Updated patch with support:
---
+       "PRIME B360-PLUS",
+       "PRIME B460-PLUS",
+       "ROG CROSSHAIR VIII DARK HERO",
+       "ROG CROSSHAIR VIII FORMULA",
+       "ROG CROSSHAIR VIII HERO",
+       "ROG CROSSHAIR VIII IMPACT",
+       "ROG STRIX B550-E GAMING",
+       "ROG STRIX B550-F GAMING",
+       "ROG STRIX B550-F GAMING (WI-FI)",
+       "ROG STRIX X570-F GAMING",
+       "ROG STRIX Z390-E GAMING",
+       "ROG STRIX Z490-I GAMING",
+       "TUF GAMING B550M-PLUS",
+       "TUF GAMING B550M-PLUS (WI-FI)",
+       "TUF GAMING B550-PLUS",
+       "TUF GAMING X570-PLUS",
+       "TUF GAMING X570-PLUS (WI-FI)",
+       "TUF GAMING X570-PRO (WI-FI)",
+       "TUF GAMING Z490-PLUS (WI-FI)",
---

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #126 from Igor (igor@svelig.com) ---
(In reply to Denis Pauk from comment #125)
> Created attachment 298887 [details]
> Add support for access via Asus WMI to nct6775 (2021.09.20)
> 
> Updated patch with support:

Could you please add my motherboard as well?

cat /sys/class/dmi/id/board_name
ROG STRIX B550-I GAMING

I mention it in the comment 104 above.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #298887|0                           |1
        is obsolete|                            |

--- Comment #127 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 298905
  --> https://bugzilla.kernel.org/attachment.cgi?id=298905&action=edit
Add support for access via Asus WMI to nct6775 (2021.09.21)

Added support by ASUSWMI:
--
+       "PRIME B360-PLUS",
+       "PRIME B460-PLUS",
+       "PRIME X570-PRO",
+       "ROG CROSSHAIR VIII DARK HERO",
+       "ROG CROSSHAIR VIII FORMULA",
+       "ROG CROSSHAIR VIII HERO",
+       "ROG CROSSHAIR VIII IMPACT",
+       "ROG STRIX B550-E GAMING",
+       "ROG STRIX B550-F GAMING",
+       "ROG STRIX B550-I GAMING",
+       "ROG STRIX B550-F GAMING (WI-FI)",
+       "ROG STRIX X570-F GAMING",
+       "ROG STRIX Z390-E GAMING",
+       "ROG STRIX Z490-I GAMING",
+       "TUF GAMING B550M-PLUS",
+       "TUF GAMING B550M-PLUS (WI-FI)",
+       "TUF GAMING B550-PLUS",
+       "TUF GAMING X570-PLUS",
+       "TUF GAMING X570-PLUS (WI-FI)",
+       "TUF GAMING X570-PRO (WI-FI)",
+       "TUF GAMING Z490-PLUS (WI-FI)",
--

I have added i2c adapter code from OpenRGB code:
--
+       "PRIME B450M-GAMING",
+       "PRIME X370-PRO",
+       "PRIME X399-A",
+       "PRIME X470-PRO",
+       "PRIME Z270-A",
+       "PRIME Z370-A",
+       "ROG CROSSHAIR VI HERO",
+       "ROG STRIX B350-F GAMING",
+       "ROG STRIX B450-F GAMING",
+       "ROG STRIX X399-E GAMING",
+       "ROG STRIX Z270-E",
+       "ROG STRIX Z370-E",
+       "ROG STRIX Z490-E GAMING",
+       "TUF B450 PLUS GAMING",
--

Could anyone with such boards check that it still works with OpenRGB? It uses
incompatible with ASUSWMI method. If it works, i will try to port to use
AsusWMI code.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #298905|0                           |1
        is obsolete|                            |

--- Comment #128 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 298971
  --> https://bugzilla.kernel.org/attachment.cgi?id=298971&action=edit
Add support for access via Asus WMI (2021.09.25)

Support by nct6775:ASUSWMI:
---
+       "PRIME B360-PLUS",
+       "PRIME B460-PLUS",
+       "PRIME X570-PRO",
+       "ROG CROSSHAIR VIII DARK HERO",
+       "ROG CROSSHAIR VIII FORMULA",
+       "ROG CROSSHAIR VIII HERO",
+       "ROG CROSSHAIR VIII IMPACT",
+       "ROG STRIX B550-E GAMING",
+       "ROG STRIX B550-F GAMING",
+       "ROG STRIX B550-F GAMING (WI-FI)",
+       "ROG STRIX B550-I GAMING",
+       "ROG STRIX X570-F GAMING",
+       "ROG STRIX Z390-E GAMING",
+       "ROG STRIX Z490-I GAMING",
+       "TUF GAMING B550M-PLUS",
+       "TUF GAMING B550M-PLUS (WI-FI)",
+       "TUF GAMING B550-PLUS",
+       "TUF GAMING B550-PRO",
+       "TUF GAMING X570-PLUS",
+       "TUF GAMING X570-PLUS (WI-FI)",
+       "TUF GAMING X570-PRO (WI-FI)",
+       "TUF GAMING Z490-PLUS (WI-FI)",
---

Support nct6775:i2c (OpenRGB code):
--
+       "PRIME B450M-GAMING",
+       "PRIME X370-PRO",
+       "PRIME X399-A",
+       "PRIME X470-PRO",
+       "PRIME Z270-A",
+       "PRIME Z370-A",
+       "ROG CROSSHAIR VI HERO",
+       "ROG STRIX B350-F GAMING",
+       "ROG STRIX B450-F GAMING",
+       "ROG STRIX X399-E GAMING",
+       "ROG STRIX Z270-E",
+       "ROG STRIX Z370-E",
+       "ROG STRIX Z490-E GAMING",
+       "TUF B450 PLUS GAMING",
--

Support ASUS WSI asus_wmi_sensors:native
(https://github.com/electrified/asus-wmi-sensors):
---
+       "ROG CROSSHAIR VII HERO (WI-FI)",
+       "ROG CROSSHAIR VII HERO",
+       "ROG CROSSHAIR VI HERO (WI-FI AC)",
+       "CROSSHAIR VI HERO",
+       "ROG CROSSHAIR VI EXTREME",
+       "ROG ZENITH EXTREME",
+       "ROG ZENITH EXTREME ALPHA",
+       "PRIME X399-A",
+       "PRIME X470-PRO",
+       "ROG STRIX X399-E GAMING",
+       "ROG STRIX B450-E GAMING",
+       "ROG STRIX B450-F GAMING",
+       "ROG STRIX B450-I GAMING",
+       "ROG STRIX X470-I GAMING",
+       "ROG STRIX X470-F GAMING",
----

Support ASUS WSI asus_wmi_sensors:ec
(https://github.com/zeule/asus-wmi-ec-sensors/blob/master):
---
+       [BOARD_R_C8H] = "ROG CROSSHAIR VIII HERO",
+       [BOARD_R_C8DH] = "ROG CROSSHAIR VIII DARK HERO",
+       [BOARD_R_C8F] = "ROG CROSSHAIR VIII FORMULA",
+       [BOARD_RS_X570_E_G] = "ROG STRIX X570-E GAMING",
+       [BOARD_RS_B550_E_G] = "ROG STRIX B550-E GAMING",
---

(In reply to Kamil Pietrzak from comment #122)
> static const u16 scale_in[15] = {
>       888, 4000, 1600, 1600, 9600, 800, 800, 1600, 1600, 1600, 1600, 1600,
> 800,
>       800, 800
> };

@Kamil Pietrzak Could you please check that scale applied to your board
correctly?

(In reply to Eugene Shalygin from comment #111)
> Thus I created a little HWMON driver [1] to read them using WMI method
> 'BREC'.

@Eugene Shalygin Could you please check that combined version is still worked?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #129 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Denis Pauk from comment #128)

> @Eugene Shalygin Could you please check that combined version is still
> worked?

Thank you for your efforts to mainline these drivers! I have a couple of
changes and questions to the EC part. Is a review going on somewhere where I
can participate? Otherwise here are the main points:

1. I'm pretty sure the B550-E GAMING board has no EC sensors. Other B550 boards
I've seen DSDT from provide a dummy BREC() function.
2. The "Water" fan sensor should have been named "Water_pump" or alike.
3. There is probably an AIO fan sensor at (2, 0x00, 0xB8) EC, but I did not yet
find time to check. Maybe someone has this header connected and can do a test
for us?

I'll try to test with hardware later today. Thank you for your work, Denis!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #130 from Kamil Pietrzak (kpietrzak@disroot.org) ---
(In reply to Denis Pauk from comment #128)

> @Kamil Pietrzak Could you please check that scale applied to your board
> correctly?

I confirm voltages defined in "static const u16 scale_in_z490[15]" are applied
correctly to my motherboard "TUF GAMING Z490-PLUS (WI-FI)".

Motherboard "TUF GAMING Z490-PLUS (WI-FI)" is using Nuvoton NCT6798D Super I/O,
so probably all motherboards that use same Nuvoton chip may benefit from those
new voltage scaling factors.
Maybe variable "static const u16 scale_in_z490" could have some more generic
name related to NCT6798D.
Here I have to admit that I figured out those voltage scaling factors by try
and error (to match voltages to those shown in Asus software on Windows), cause
I could not find Nuvoton NCT6798D documentation on Nuvoton website.

Also I think it is probaby safe to add motherboard "TUF GAMING Z490-PLUS" to
supported boards, case as far as I know the only difference between "TUF GAMING
Z490-PLUS" and "TUF GAMING Z490-PLUS (WI-FI)" is Intel Wi-Fi 6 AX201 chip on
the latter.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #131 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Eugene Shalygin from comment #129)
> Thank you for your efforts to mainline these drivers! I have a couple of
> changes and questions to the EC part. Is a review going on somewhere where I
> can participate? Otherwise here are the main points:
> 
I have not sent it to review yet. I prefer to have checked at least one
motherboard from each group before send for review. Especially i2c adapter. 

(In reply to Eugene Shalygin from comment #129)
> 1. I'm pretty sure the B550-E GAMING board has no EC sensors. Other B550
> boards I've seen DSDT from provide a dummy BREC() function.

As for me it has returned reasonable values for "ROG STRIX B550-E GAMING":
----
asuswmiecsensors-isa-0000
Adapter: ISA adapter
Chipset:      +32.0°C  
CPU:          +22.0°C  
Motherboard:  +22.0°C  
T_Sensor:    +216.0°C  
VRM:          +28.0°C  

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +25.1°C  
Tdie:         +25.1°C  
Tccd1:        +22.5°C  
Tccd2:        +24.5°C 
----

Maybe it has other valuable sensors, I have used some lucky values for now that
looks as reasonable. Motherboard for sure has T_Sensor and AIO_PUMP by
https://rog.asus.com/motherboards/rog-strix/rog-strix-b550-e-gaming-model/spec.

(In reply to Kamil Pietrzak from comment #130)
> Motherboard "TUF GAMING Z490-PLUS (WI-FI)" is using Nuvoton NCT6798D Super
> I/O, so probably all motherboards that use same Nuvoton chip may benefit
> from those new voltage scaling factors.  

What do you think about use kernel mode parameter for use custom value until we
will have some approve that other motherboards with NCT6798D has same scale
factors?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #132 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
(In reply to Denis Pauk from comment #131)
> (In reply to Eugene Shalygin from comment #129)
> > Thank you for your efforts to mainline these drivers! I have a couple of
> > changes and questions to the EC part. Is a review going on somewhere where
> I
> > can participate? Otherwise here are the main points:
> > 
> I have not sent it to review yet. I prefer to have checked at least one
> motherboard from each group before send for review. Especially i2c adapter. 

Don't forget to split per logical change (to me sounds like new code contains 3
to 5 logical pieces, hence the number of patches).

> (In reply to Kamil Pietrzak from comment #130)
> > Motherboard "TUF GAMING Z490-PLUS (WI-FI)" is using Nuvoton NCT6798D Super
> > I/O, so probably all motherboards that use same Nuvoton chip may benefit
> > from those new voltage scaling factors.  
> 
> What do you think about use kernel mode parameter for use custom value until
> we will have some approve that other motherboards with NCT6798D has same
> scale factors?

Once added, parameter may not be removed (because we don't break user space).
So, this parameter is not so critical and I am definitely against adding it.

The compromise would be to name after the tested board (with probably comment
in the commit message and/or the code that this is possible to have the same
for all NCT6789D chips) and when confirmed, rename as Kamil proposed.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #298971|0                           |1
        is obsolete|                            |

--- Comment #133 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 299111
  --> https://bugzilla.kernel.org/attachment.cgi?id=299111&action=edit
Add support for access via Asus WMI (2021.10.05)

Patch with same list of supported boards, additionally applied changes from
review https://lkml.org/lkml/2021/10/2/189.

(In reply to Kamil Pietrzak from comment #130)
> I confirm voltages defined in "static const u16 scale_in_z490[15]" are
> applied correctly to my motherboard "TUF GAMING Z490-PLUS (WI-FI)".
I afraid next patch will be without scaling :-(
https://lkml.org/lkml/2021/10/5/707

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #134 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
Denis, 

thank you for pulling the new changes!

Could you explain, please, why did you merge the asus-wmi-sensors and
asus-wmi-ec-sensors drivers? As far as I understand, asus-wmi-sensors can fetch
data from all available sensors, including those provided by EC, but the WMI
methods it relies upon are removed from the new ASUS boards.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #135 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Eugene Shalygin from comment #134)
> Denis, 
> 
> thank you for pulling the new changes!
> 
> Could you explain, please, why did you merge the asus-wmi-sensors and
> asus-wmi-ec-sensors drivers? As far as I understand, asus-wmi-sensors can
> fetch data from all available sensors, including those provided by EC, but
> the WMI methods it relies upon are removed from the new ASUS boards.
Both drivers have used same entry point and difference as I see that: old
boards return some list of sensors with names, new one always returns zero as
count of sensors and requires some hardcoded list of sensors. And list of old
and new boards is not intersected. 

As for me, when we have 30% of similar code better have one driver for both
cases. Currently driver has 1126 lines.

(I have not calculated real size of shared code so it can be bigger or less.)

Do you like to be in MAINTAINERS list?

Also good news, no EC also will go in next round of updated patches. 
https://github.com/electrified/asus-wmi-sensors/issues/78

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #136 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Denis Pauk from comment #135)
> Both drivers have used same entry point and difference as I see that: old
> boards return some list of sensors with names,

There was a special WMI interface that reads all sensors, both from SIO and EC,
kind implementing what you did for the nct driver and what is implemented in
the asus-wmi-ec-sensors, but done fully in the DSDT code. 

> new one always returns zero as count of sensors

There is simply no that high-level WMI interface in the new boards.

> and requires some hardcoded list of sensors.

I now think the EC sensors are at the same registers for the old and new
boards.  

> And list of old and new boards is not intersected. 

Exactly! So half the driver will be a dead code anyway. Would it be better to
load only one of the small drivers? Also, for the old boards the nct6775 driver
will load and asus-wmi-sensors provides duplicate readings.  
> 
> As for me, when we have 30% of similar code better have one driver for both
> cases. Currently driver has 1126 lines.

The only shared code between those two is the HWMON interface functions, which
is more or less the same for many HWMON drivers. 

So, would it be simpler to provide 3 drivers: nct6775, asus-wmi-sensors,
asus-wmi-ec-sensors?

> Do you like to be in MAINTAINERS list?

Yes, please. I still have work to do with that (even not all available sensors
are discovered yet).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #137 from Kamil Pietrzak (kpietrzak@disroot.org) ---
(In reply to Denis Pauk from comment #133)
> I afraid next patch will be without scaling :-(
> https://lkml.org/lkml/2021/10/5/707

I am not kernel developer but I also think per motherboard voltage scalling is
bad idea in terms of maintenance. For the same reason hardcoding any of board
models in module code is rather bad idea and personally I would prefer to use
for example use_wmi=y module parameter or similar when resource conflict occurs
on module loading.

With regard to current voltage scaling factors for nct6798d chip, they are most
likely not correct and probably will require future changes. For example I
can't see +12V and +5V is sensors output when using current voltage scalling
factors.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #138 from Kamil Pietrzak (kpietrzak@disroot.org) ---
(In reply to Kamil Pietrzak from comment #137)
> With regard to current voltage scaling factors for nct6798d chip, they are
> most likely not correct and probably will require future changes. For
> example I can't see +12V and +5V is sensors output when using current
> voltage scalling factors.

Partially responding to my own comment here.

Due to the lack of publicly available documentation for NCT6798D chip I checked
docs for similar chips (NCT6791D, NCT6791D).

Looks like voltages like +12V and +5V can be connected to any one of general
purpose voltage inputs on the SuperIO chip. So on one motherboard +12V can be
connected to pin VIN0, but on another one with same SuperIO chip it can
possibly be connected to other general purpose voltage pin like VIN1, VIN2,
VIN3 etc. In that case it will not be possible to properly scale these voltages
without hardcoding motherboard models in module code, so scaling should take
place in userspace apps like lm_sensors. The only voltages that can be safely
scaled in module code are Vcore, AVSB, 3VCC, 3VSB, VBAT. Pins to which they are
connected should not change between different motherboards. So it looks like
current voltage scaling factors are as accurate as it can be without hardcoding
motherboards models.

However, I am still curious about Vcore voltage readings on my TUF Z490 board
in BIOS and Asus software. According to docs Vcore should be calculated with
formula 

Detected Voltage = Reading * 0.008 V

but Asus in BIOS and in their software on Windows calculate it probably with
some additional scaling factor, most likely something like

Detected Voltage = Reading * 0.008 V * 1.11

The only reason that comes to my mind for calculating Vcore in that way is that
they (Asus) wanted BIOS/software Vcore readings to be more accurate in relation
to voltage readings using for example multimeter near the CPU socket.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #299111|0                           |1
        is obsolete|                            |

--- Comment #139 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 299159
  --> https://bugzilla.kernel.org/attachment.cgi?id=299159&action=edit
Add support for access via Asus WMI (2021.10.10)

Rebased over
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/log/?h=hwmon-next

Sent to LKML(without unchecked i2c logic): https://lkml.org/lkml/2021/10/10/65

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #141 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
I would like to ask for an assistance to understand why reading EC sensors
takes so much time (1 second). Could, please, users of boards with sensors
published in EC registers (we currently aware of the following models:  Pro WS
X570-ACE, ROG Crosshair VIII Hero, ROG Crosshair VIII Dark Hero, ROG Crosshair
VIII Formula, G STRIX B550-E GAMING, ROG STRIX X570-E GAMING) measure how long
does it take to read all 256 EC registers in their system and report back the
time and the board name?

# modprobe ec_sys
# time cat /sys/kernel/debug/ec/ec0/io > /dev/null

Thank you!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #142 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
(In reply to Feliks from comment #140)
> Can someone add my board please? It is an Asus PRIME X570-P, I guess the
> sensor should be, if not exactly the same, as the one from an Asus PRIME
> X570-Pro.
> I cannot use Linux with my board since the CPU fan is spinning at maximum
> speed making an extreme amount of noise, due to that module's sensor
> readings which are wrong.

You have to test yourself before anybody else will add it.

(In reply to Eugene Shalygin from comment #141)
> I would like to ask for an assistance to understand why reading EC sensors
> takes so much time (1 second). Could, please, users of boards with sensors
> published in EC registers (we currently aware of the following models:  Pro
> WS X570-ACE, ROG Crosshair VIII Hero, ROG Crosshair VIII Dark Hero, ROG
> Crosshair VIII Formula, G STRIX B550-E GAMING, ROG STRIX X570-E GAMING)
> measure how long does it take to read all 256 EC registers in their system
> and report back the time and the board name?
> 
> # modprobe ec_sys
> # time cat /sys/kernel/debug/ec/ec0/io > /dev/null

It won't mean anything. The each register read separately may take a long time
since EC is a separate uController that may be interrupted at any time by any
higher priority task (to be sure you have to have a look into the firmware
source code). So, I'll be not surprised if 1s in some cases is not enough. Not
I'm against the shrtening the timeouts, but somebody should really know what
they are about and why.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #143 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Andy Shevchenko from comment #142)

> It won't mean anything. The each register read separately may take a long
> time since EC is a separate uController that may be interrupted at any time
> by any higher priority task (to be sure you have to have a look into the
> firmware source code). So, I'll be not surprised if 1s in some cases is not
> enough. Not I'm against the shrtening the timeouts, but somebody should
> really know what they are about and why.

I'm looking for a rough estimate. All my other machines need less than 0.3 s
for that, and only the ASUS one never completes in less than 2.7 s.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Jarkko Korpi (temp82@luukku.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |temp82@luukku.com

--- Comment #146 from Jarkko Korpi (temp82@luukku.com) ---
Please add also Asus z390 rog strix f-gaming.

[    3.685656] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[    3.685747] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20190816/utaddress-204)
[    3.685750] ACPI: If an ACPI driver is available for this device, you should
use it instead of the native driver

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #147 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Jarkko Korpi from comment #146)
> Please add also Asus z390 rog strix f-gaming.
> 
> [    3.685656] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
> [    3.685747] ACPI Warning: SystemIO range
> 0x0000000000000295-0x0000000000000296 conflicts with OpRegion
> 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20190816/utaddress-204)
> [    3.685750] ACPI: If an ACPI driver is available for this device, you
> should use it instead of the native driver

Have you tried to run
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/log/?h=hwmon-next
with added your board to list?

Could you also share exact name of board from /sys/class/dmi/id/board_name?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #148 from Jarkko Korpi (temp82@luukku.com) ---
 cat /sys/class/dmi/id/board_name 
ROG STRIX Z390-F GAMING

no I haven'y tried the patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Olli Asikainen (olli.asikainen@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olli.asikainen@gmail.com

--- Comment #149 from Olli Asikainen (olli.asikainen@gmail.com) ---
My ancient MAXIMUS VII HERO (NCT6791D) suffers from this bug as well.

I added the board name to asus_wmi_boards, but this is what I get:

[    3.131718] nct6775: Using Asus WMI to access 0x0 chip.
[    3.131742] nct6775: Enabling hardware monitor logical device mappings.
[    3.131750] nct6775: Found NCT6791D or compatible chip at 0x2e:0x290

nct6791-isa-0290
Adapter: ISA adapter
Vcore:                   0.00 V  (min =  +0.00 V, max =  +0.00 V)
in1:                     0.00 V  (min =  +0.00 V, max =  +0.00 V)
AVCC:                    0.00 V  (min =  +0.00 V, max =  +0.00 V)
+3.3V:                   0.00 V  (min =  +0.00 V, max =  +0.00 V)
in4:                     0.00 V  (min =  +0.00 V, max =  +0.00 V)
in5:                     0.00 V  (min =  +0.00 V, max =  +0.00 V)
in6:                     0.00 V  (min =  +0.00 V, max =  +0.00 V)
3VSB:                    0.00 V  (min =  +0.00 V, max =  +0.00 V)
Vbat:                    0.00 V  (min =  +0.00 V, max =  +0.00 V)
in9:                     0.00 V  (min =  +0.00 V, max =  +0.00 V)
in10:                    0.00 V  (min =  +0.00 V, max =  +0.00 V)
in11:                    0.00 V  (min =  +0.00 V, max =  +0.00 V)
in12:                    0.00 V  (min =  +0.00 V, max =  +0.00 V)
in13:                    0.00 V  (min =  +0.00 V, max =  +0.00 V)
in14:                    0.00 V  (min =  +0.00 V, max =  +0.00 V)
fan1:                     0 RPM  (min =    0 RPM)
fan2:                     0 RPM  (min =    0 RPM)
fan3:                     0 RPM  (min =    0 RPM)
fan4:                     0 RPM  (min =    0 RPM)
fan5:                     0 RPM  (min =    0 RPM)
SYSTIN:                  +0.0°C  (high =  +0.0°C, hyst =  +0.0°C)  sensor =
thermistor
CPUTIN:                  +0.0°C  (high =  +0.0°C, hyst =  +0.0°C)  sensor =
thermistor
AUXTIN0:                 +0.0°C    sensor = thermistor
AUXTIN1:                 +0.0°C    sensor = thermistor
AUXTIN2:                 +0.0°C    sensor = thermistor
AUXTIN3:                 +0.0°C    sensor = thermistor
PCH_CHIP_CPU_MAX_TEMP:   +0.0°C
PCH_CHIP_TEMP:           +0.0°C
PCH_CPU_TEMP:            +0.0°C
PCH_MCH_TEMP:            +0.0°C
intrusion0:            OK
intrusion1:            OK
beep_enable:           disabled

Any idea?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #150 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Olli Asikainen from comment #149)
> My ancient MAXIMUS VII HERO (NCT6791D) suffers from this bug as well.
> 
> I added the board name to asus_wmi_boards, but this is what I get: ...
> Any idea?

Please share your DSDT ACPI table (/sys/firmware/acpi/tables/DSDT or acpidump
-b -n DSDT).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #152 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Olli Asikainen from comment #151)
> Created attachment 299459 [details]
> acpidump -b -n DSDT

This motherboard has totally different firmware, neither like the ones
supported by Denis patch, nor those supported by the asus-wmi-sensors driver.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #153 from Olli Asikainen (olli.asikainen@gmail.com) ---
Yeah, it's old and suffers from the same bug, but I reckon supporting this
would be a completely different story. Thanks for your answer Eugene and sorry
for the noise.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #154 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Olli Asikainen from comment #153)
> Yeah, it's old and suffers from the same bug, but I reckon supporting this
> would be a completely different story. Thanks for your answer Eugene and
> sorry for the noise.

This firmware seem to be using ACPI mutex named \_SB_.PCI0.LPCB.SIO1.MUT0 to
guard access to the nct chip registers.

I wonder, can we rely on these mutexes, whose names seem to be quite stable, as
well, instead of the WMI functions? Then accessing nct registers would become
simpler: lock ACPI mutex if needed, access registers always in the regular way,
unlock the mutex.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #155 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
(In reply to Eugene Shalygin from comment #154)
> (In reply to Olli Asikainen from comment #153)
> > Yeah, it's old and suffers from the same bug, but I reckon supporting this
> > would be a completely different story. Thanks for your answer Eugene and
> > sorry for the noise.
> 
> This firmware seem to be using ACPI mutex named \_SB_.PCI0.LPCB.SIO1.MUT0 to
> guard access to the nct chip registers.
> 
> I wonder, can we rely on these mutexes, whose names seem to be quite stable,
> as well, instead of the WMI functions? Then accessing nct registers would
> become simpler: lock ACPI mutex if needed, access registers always in the
> regular way, unlock the mutex.

There is a _SEM (semaphore) handling example in the upstream:
https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-designware-baytrail.c
https://elixir.bootlin.com/linux/latest/source/arch/x86/platform/intel/iosf_mbi.c#L275
maybe something similar can be done for ACPI Mutex() object.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #156 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Andy Shevchenko from comment #155)

I use acpi_acquire_mutex()/acpi_release_mutex() for the ASUS EC sensors driver
(https://github.com/zeule/asus-ec-sensors/blob/master/asus-ec-sensors.c#L417),
but there seem to be no other users of these function inside the kernel sources
(checked 5.15.0)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #157 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
(In reply to Eugene Shalygin from comment #156)
> (In reply to Andy Shevchenko from comment #155)
> 
> I use acpi_acquire_mutex()/acpi_release_mutex() for the ASUS EC sensors
> driver
> (https://github.com/zeule/asus-ec-sensors/blob/master/asus-ec-sensors.
> c#L417), but there seem to be no other users of these function inside the
> kernel sources (checked 5.15.0)

Looks legit. Object is passed by handle:path.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #299159|0                           |1
        is obsolete|                            |

--- Comment #159 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 299483
  --> https://bugzilla.kernel.org/attachment.cgi?id=299483&action=edit
Check MAXIMUS_VII_HERO by lock mutex directly

(In reply to Olli Asikainen from comment #151)
> Created attachment 299459 [details]
> acpidump -b -n DSDT

Could you check with updated patch? It has only nct6798d part and only for
check idea.

As I see by your logs and dsdt - all call returned just zero and DSDT does not
have RSIO/WRIO methods.

Could you please check with patch?

(In reply to Eugene Shalygin from comment #154)
> (In reply to Olli Asikainen from comment #153)
> > Yeah, it's old and suffers from the same bug, but I reckon supporting this
> > would be a completely different story. Thanks for your answer Eugene and
> > sorry for the noise.
> 
> This firmware seem to be using ACPI mutex named \_SB_.PCI0.LPCB.SIO1.MUT0 to
> guard access to the nct chip registers.
> 
> I wonder, can we rely on these mutexes, whose names seem to be quite stable,
> as well, instead of the WMI functions? Then accessing nct registers would
> become simpler: lock ACPI mutex if needed, access registers always in the
> regular way, unlock the mutex.

It looks as different for different boards, B550-E uses
"\\_SB.PCI0.SBRG.SIO1.MUT0" as mutex name.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #160 from Jarkko Korpi (temp82@luukku.com) ---
if someone provides a patch for ROG STRIX Z390-F GAMING I am willing to give it
a try against up to date Linu's git tree.

where exactly I find this new patch from sudo make menuconfig?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #161 from Olli Asikainen (olli.asikainen@gmail.com) ---
(In reply to Denis Pauk from comment #159)
> Created attachment 299483 [details]
> Check MAXIMUS_VII_HERO by lock mutex directly
> 
> (In reply to Olli Asikainen from comment #151)
> > Created attachment 299459 [details]
> > acpidump -b -n DSDT
> 
> Could you check with updated patch? It has only nct6798d part and only for
> check idea.

It works! (as far as I can tell)

[    5.109607] nct6775: Using Asus WMI mutex.
[    5.109633] nct6775: Enabling hardware monitor logical device mappings.
[    5.109641] nct6775: Found NCT6791D or compatible chip at 0x2e:0x290

nct6791-isa-0290
Adapter: ISA adapter
Vcore:                 928.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                   1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
AVCC:                    3.31 V  (min =  +2.98 V, max =  +3.63 V)
+3.3V:                   3.31 V  (min =  +2.98 V, max =  +3.63 V)
in4:                   1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                     1.94 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                     0.00 V  (min =  +0.00 V, max =  +0.00 V)
3VSB:                    3.42 V  (min =  +2.98 V, max =  +3.63 V)
Vbat:                    3.30 V  (min =  +2.70 V, max =  +3.63 V)
in9:                     1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                    0.00 V  (min =  +0.00 V, max =  +0.00 V)
in11:                  936.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                    0.00 V  (min =  +0.00 V, max =  +0.00 V)
in13:                    8.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                    8.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                     0 RPM  (min =    0 RPM)
fan2:                     0 RPM  (min =    0 RPM)
fan3:                     0 RPM  (min =    0 RPM)
fan4:                     0 RPM  (min =    0 RPM)
fan5:                     0 RPM  (min =    0 RPM)
fan6:                     0 RPM  (min =    0 RPM)
SYSTIN:                 +28.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM 
sensor = thermistor
CPUTIN:                 +30.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:               -128.0°C    sensor = thermistor
AUXTIN1:               -128.0°C    sensor = thermistor
AUXTIN2:                +29.0°C    sensor = thermistor
AUXTIN3:               +127.0°C    sensor = thermistor
PECI Agent 0:           +30.0°C
PCH_CHIP_CPU_MAX_TEMP:   +0.0°C
PCH_CHIP_TEMP:           +0.0°C
PCH_CPU_TEMP:            +0.0°C
intrusion0:            ALARM
intrusion1:            ALARM
beep_enable:           disabled

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #162 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Denis Pauk from comment #159)

> It looks as different for different boards, B550-E uses
> "\\_SB.PCI0.SBRG.SIO1.MUT0" as mutex name.

Then we are better off with a platform driver that provides these mutexes if
required and known, that can be used by both nct6775 and ec sensors modules?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #299483|0                           |1
        is obsolete|                            |

--- Comment #163 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 299517
  --> https://bugzilla.kernel.org/attachment.cgi?id=299517&action=edit
Rebased patch with all asus_* drivers and i2c 11.11.2021

Patch rebased over
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/tag/?h=hwmon-for-v5.16
tag. 

Could someone also check i2c adapter? It should work for all boards with direct
access to NCT67xx or with known acpi mutex name and available for:
    "PRIME B450M-GAMING",
    "PRIME X370-PRO",
    "PRIME X399-A",
    "PRIME X470-PRO",
    "PRIME Z270-A",
    "PRIME Z370-A",
    "ROG CROSSHAIR VI HERO",
    "ROG STRIX B350-F GAMING",
    "ROG STRIX B450-F GAMING",
    "ROG STRIX X399-E GAMING",
    "ROG STRIX Z270-E",
    "ROG STRIX Z370-E",
    "ROG STRIX Z490-E GAMING",
    "TUF B450 PLUS GAMING",

As:
---
cat /sys/bus/i2c/devices/i2c-8/name 
SMBus NCT67xx adapter at 0295
---

i2c bus can be checked by:
---
modprobe i2c-dev
i2cdetect 8
---

I2c adapter code is based on patch from OpenRGB repository.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #164 from Joel Wirāmu (jwp@redhat.com) ---
Another board to add:
Product Name: PRIME B550M-A (WI-FI)
[  105.876155] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290

On Thu, 11 Nov 2021 at 11:36, <bugzilla-daemon@bugzilla.kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=204807
>
> Denis Pauk (pauk.denis@gmail.com) changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>  Attachment #299483|0                           |1
>         is obsolete|                            |
>
> --- Comment #163 from Denis Pauk (pauk.denis@gmail.com) ---
> Created attachment 299517
>   --> https://bugzilla.kernel.org/attachment.cgi?id=299517&action=edit
> Rebased patch with all asus_* drivers and i2c 11.11.2021
>
> Patch rebased over
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/tag/?h=hwmon-for-v5.16
> tag.
>
> Could someone also check i2c adapter? It should work for all boards with
> direct
> access to NCT67xx or with known acpi mutex name and available for:
>     "PRIME B450M-GAMING",
>     "PRIME X370-PRO",
>     "PRIME X399-A",
>     "PRIME X470-PRO",
>     "PRIME Z270-A",
>     "PRIME Z370-A",
>     "ROG CROSSHAIR VI HERO",
>     "ROG STRIX B350-F GAMING",
>     "ROG STRIX B450-F GAMING",
>     "ROG STRIX X399-E GAMING",
>     "ROG STRIX Z270-E",
>     "ROG STRIX Z370-E",
>     "ROG STRIX Z490-E GAMING",
>     "TUF B450 PLUS GAMING",
>
> As:
> ---
> cat /sys/bus/i2c/devices/i2c-8/name
> SMBus NCT67xx adapter at 0295
> ---
>
> i2c bus can be checked by:
> ---
> modprobe i2c-dev
> i2cdetect 8
> ---
>
> I2c adapter code is based on patch from OpenRGB repository.
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are on the CC list for the bug.
>
>

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #165 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Eugene Shalygin from comment #162)
> (In reply to Denis Pauk from comment #159)
> 
> > It looks as different for different boards, B550-E uses
> > "\\_SB.PCI0.SBRG.SIO1.MUT0" as mutex name.
> 
> Then we are better off with a platform driver that provides these mutexes if
> required and known, that can be used by both nct6775 and ec sensors modules?

Maybe we can have asus_wmi_info_table from patch in #163 as shared file with
description of preferred method for access, acpi mutext name, devices on i2c
bus, ec register address to sensor type. What do you think?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #166 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Joel Wirāmu from comment #164)
> Another board to add:
> Product Name: PRIME B550M-A (WI-FI)
> [  105.876155] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
> 

I will add as part of next patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #167 from Olli Asikainen (olli.asikainen@gmail.com) ---
(In reply to Denis Pauk from comment #163)
> Created attachment 299517 [details]
> Rebased patch with all asus_* drivers and i2c 11.11.2021

Thank you Denis!

A small correction for MAXIMUS VII HERO, the board name is actually "MAXIMUS
VII HERO" not "ROG MAXIMUS VII HERO".

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #168 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Denis Pauk from comment #165)

> Maybe we can have asus_wmi_info_table from patch in #163 as shared file with
> description of preferred method for access, acpi mutext name, devices on i2c
> bus, ec register address to sensor type. What do you think?

My idea was that the mutex for the state lock can be either the regular mutex
or the ACPI mutex, there is no need to lock both of them simultaneously. So
that the module can return a structure with the mutex (ACPI one if known for
the given hardware or the regular one) and functions to lock and unlock it. I
just thought that would make logic in the actual sensor modules (nct or ec)
simpler.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #299517|0                           |1
        is obsolete|                            |

--- Comment #169 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 299537
  --> https://bugzilla.kernel.org/attachment.cgi?id=299537&action=edit
Rebased patch with fixed board names 11.11.2021

(In reply to Olli Asikainen from comment #167)
> (In reply to Denis Pauk from comment #163)
> > Created attachment 299517 [details]
> > Rebased patch with all asus_* drivers and i2c 11.11.2021
> 
> Thank you Denis!
> 
> A small correction for MAXIMUS VII HERO, the board name is actually "MAXIMUS
> VII HERO" not "ROG MAXIMUS VII HERO".

Could you check?

(In reply to Joel Wirāmu from comment #164)
> Created attachment 299519 [details]
> attachment-16225-0.html
> 
> Another board to add:
> Product Name: PRIME B550M-A (WI-FI)
> [  105.876155] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
> 

Could you check?

(In reply to Eugene Shalygin from comment #168)
> (In reply to Denis Pauk from comment #165)
> 
> > Maybe we can have asus_wmi_info_table from patch in #163 as shared file
> with
> > description of preferred method for access, acpi mutext name, devices on
> i2c
> > bus, ec register address to sensor type. What do you think?
> 
> My idea was that the mutex for the state lock can be either the regular
> mutex or the ACPI mutex, there is no need to lock both of them
> simultaneously. So that the module can return a structure with the mutex
> (ACPI one if known for the given hardware or the regular one) and functions
> to lock and unlock it. I just thought that would make logic in the actual
> sensor modules (nct or ec) simpler.

Could you look to nct6775_data:{un}lock? Do you mean something like it?

(In reply to Andy Shevchenko from comment #157)
> (In reply to Eugene Shalygin from comment #156)
> > (In reply to Andy Shevchenko from comment #155)
> > 
> > I use acpi_acquire_mutex()/acpi_release_mutex() for the ASUS EC sensors
> > driver
> > (https://github.com/zeule/asus-ec-sensors/blob/master/asus-ec-sensors.
> > c#L417), but there seem to be no other users of these function inside the
> > kernel sources (checked 5.15.0)
> 
> Looks legit. Object is passed by handle:path.

Could we enable create i2c adapter for all direct access cases? Connected
devices(RGB leds?) should be in safe conditions by default without read/write
by this adapter and code reuses same lock as monitoring code.   

What do you think?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #170 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Denis Pauk from comment #169)

> Could you look to nct6775_data:{un}lock? Do you mean something like it?

Yes, something like that. I think if we hide that under a formal interface and
put in a module, it can be used in both hwmon drivers. And yes, I believe we
should query EC directly, because the WMI functions are simply wrappers that
end up at the same calls to ec_read(). Since we going to lock the ACPI mutex
ourselves, there is no reason to use WMI functions to access EC registers.

Here is what I thought of:

union access_lock_data {
         struct mutex lock;
         struct {
                acpi_handle aml_mutex[MAX_ACPI_MUTEX_COUNT]; // maybe there is
a firmware where there is no single mutex to guard both chips?
                int acpi_mutex_count;
         } acpi_lock;
};

struct access_lock_funcs {
        int (*lock)(access_lock_funcs* funcs);
        int (*unlock)(access_lock_funcs* funcs);
};

struct access_lock_state {
        union access_lock_data data;
        struct access_lock_funcs funcs;
};

int get_access_lock(int flags, struct access_lock_funcs* res); // flags to tell
what needs to be guarded (HWMON chip, EC, or both)
void free_access_lock(struct access_lock_funcs* funcs);

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #171 from Andy Shevchenko (andy.shevchenko@gmail.com) ---
(In reply to Eugene Shalygin from comment #170)
> (In reply to Denis Pauk from comment #169)
> 
> > Could you look to nct6775_data:{un}lock? Do you mean something like it?
> 
> Yes, something like that.

With all my respect, folks, please move this kind of discussions to the mailing
list. I'm going now to mark similar comments as private so real users won't
suffer reading these technical details which they are not interested in. I hope
you understand my motivation.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #172 from Gregory Duhamel (gregory.duhamel@gmail.com) ---
Hello Guys,

uname -a  
Linux 5.16.0-0.rc1.20211115git8ab774587903.14.vanilla.1.fc35.x86_64 #1 SMP
PREEMPT Tue Nov 16 12:36:08 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

sensors
nct6798-isa-0290
Adapter: ISA adapter
in0:                        1.20 V  (min =  +0.00 V, max =  +1.74 V)
fan1:                      883 RPM  (min =    0 RPM)
fan2:                      596 RPM  (min =    0 RPM)
fan3:                      820 RPM  (min =    0 RPM)
fan6:                     1081 RPM  (min =    0 RPM)
SYSTIN:                    +31.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +37.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +26.0°C    sensor = thermistor
AUXTIN1:                  +127.0°C    sensor = thermistor
AUXTIN2:                  +109.0°C    sensor = thermistor
AUXTIN3:                   +23.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +37.5°C
[...]


Thanks a lot everyone ! Special though to Denis and everyone contributing.

Regards,
Gregory.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #299537|0                           |1
        is obsolete|                            |

--- Comment #173 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 299757
  --> https://bugzilla.kernel.org/attachment.cgi?id=299757&action=edit
Rebased patch with i2c v5.15 28.11.2021

Code have sent as part of https://lkml.org/lkml/2021/11/28/225 + i2c.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Mikhail (mikhail.v.gavrilov@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikhail.v.gavrilov@gmail.co
                   |                            |m

--- Comment #174 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
(In reply to Denis Pauk from comment #173)
> Created attachment 299757 [details]
> Rebased patch with i2c v5.15 28.11.2021
> 
> Code have sent as part of https://lkml.org/lkml/2021/11/28/225 + i2c.

I see that my M/B "ROG STRIX X570-I GAMING" not listed in patch. And yes I
checked patch and can confirm that CPU FAN sensor monitoring still absent for
my M/B with this patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #175 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Mikhail from comment #174)
> (In reply to Denis Pauk from comment #173)
> > Created attachment 299757 [details]
> > Rebased patch with i2c v5.15 28.11.2021
> > 
> > Code have sent as part of https://lkml.org/lkml/2021/11/28/225 + i2c.
> 
> I see that my M/B "ROG STRIX X570-I GAMING" not listed in patch. And yes I
> checked patch and can confirm that CPU FAN sensor monitoring still absent
> for my M/B with this patch.

What do you mean by missing "CPU FAN"? It has returned zero or does not exist
in listing? 

It case it has returned zero, could you attach result of "acpidump -b -n DSDT"
?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #176 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
> What do you mean by missing "CPU FAN"? It has returned zero or does not exist
> in listing? 

It has returned always zero even before your patch.


$ sensors
hidpp_battery_0-hid-3-10
Adapter: HID adapter
in0:           3.80 V  

amdgpu-pci-0b00
Adapter: PCI adapter
vddgfx:      775.00 mV 
fan1:           0 RPM  (min =    0 RPM, max = 3300 RPM)
edge:         +52.0°C  (crit = +100.0°C, hyst = -273.1°C)
                       (emerg = +105.0°C)
junction:     +55.0°C  (crit = +110.0°C, hyst = -273.1°C)
                       (emerg = +115.0°C)
mem:          +54.0°C  (crit = +100.0°C, hyst = -273.1°C)
                       (emerg = +105.0°C)
power1:       22.00 W  (cap = 255.00 W)

nvme-pci-0100
Adapter: PCI adapter
Composite:    +50.9°C  

iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:        +54.0°C  

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +76.6°C  
Tccd1:        +71.0°C  
Tccd2:        +74.5°C  

ucsi_source_psy_0_00081-i2c-0-08
Adapter: Synopsys DesignWare I2C adapter
in0:           0.00 V  (min =  +0.00 V, max =  +0.00 V)
curr1:         0.00 A  (max =  +0.00 A)


> It case it has returned zero, could you attach result of "acpidump -b -n
> DSDT" ?

[mikhail@primary-ws ~]$ sudo acpidump -b -n DSDT
[mikhail@primary-ws ~]$

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #177 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
Oh sorry it does not exist I looked at the GPU sensors by mistake.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #178 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Mikhail from comment #176)
> > What do you mean by missing "CPU FAN"? It has returned zero or does not
> exist
> > in listing? 
> 
> It has returned always zero even before your patch.
> 
> 
> $ sensors
> hidpp_battery_0-hid-3-10
> Adapter: HID adapter
> in0:           3.80 V  
> 
> amdgpu-pci-0b00
> Adapter: PCI adapter
> vddgfx:      775.00 mV 
> fan1:           0 RPM  (min =    0 RPM, max = 3300 RPM)
> edge:         +52.0°C  (crit = +100.0°C, hyst = -273.1°C)
>                        (emerg = +105.0°C)
> junction:     +55.0°C  (crit = +110.0°C, hyst = -273.1°C)
>                        (emerg = +115.0°C)
> mem:          +54.0°C  (crit = +100.0°C, hyst = -273.1°C)
>                        (emerg = +105.0°C)
> power1:       22.00 W  (cap = 255.00 W)
> 
> nvme-pci-0100
> Adapter: PCI adapter
> Composite:    +50.9°C  
> 
> iwlwifi_1-virtual-0
> Adapter: Virtual device
> temp1:        +54.0°C  
> 
> k10temp-pci-00c3
> Adapter: PCI adapter
> Tctl:         +76.6°C  
> Tccd1:        +71.0°C  
> Tccd2:        +74.5°C  
> 
> ucsi_source_psy_0_00081-i2c-0-08
> Adapter: Synopsys DesignWare I2C adapter
> in0:           0.00 V  (min =  +0.00 V, max =  +0.00 V)
> curr1:         0.00 A  (max =  +0.00 A)
> 
> 
What do you have in dmesg when you load driver?

> > It case it has returned zero, could you attach result of "acpidump -b -n
> > DSDT" ?
> 
> [mikhail@primary-ws ~]$ sudo acpidump -b -n DSDT
> [mikhail@primary-ws ~]$

acpidump should create binary dump of DSDT section(dsdt.dat) of your board,
could you attach it here?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #179 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
Created attachment 299883
  --> https://bugzilla.kernel.org/attachment.cgi?id=299883&action=edit
dsdt.dat (ROG STRIX X570-I GAMING)

> acpidump should create binary dump of DSDT section(dsdt.dat) of your board,
> could you attach it here?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #180 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
> What do you have in dmesg when you load driver?

[11492.230845] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[11492.230925] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210930/utaddress-204)
[11492.230937] ACPI: OSL: Resource conflict; ACPI support missing from driver?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #299757|0                           |1
        is obsolete|                            |

--- Comment #181 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 299887
  --> https://bugzilla.kernel.org/attachment.cgi?id=299887&action=edit
Add X570-I mutex

Could you check with updated patch?  

(In reply to Mikhail from comment #179)
> Created attachment 299883 [details]
> dsdt.dat (ROG STRIX X570-I GAMING)
> 
> > acpidump should create binary dump of DSDT section(dsdt.dat) of your board,
> > could you attach it here?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Vladdrako (vladdrako007@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vladdrako007@gmail.com

--- Comment #182 from Vladdrako (vladdrako007@gmail.com) ---
Created attachment 299891
  --> https://bugzilla.kernel.org/attachment.cgi?id=299891&action=edit
dsdt dump p8z68-v lx

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #183 from Vladdrako (vladdrako007@gmail.com) ---
Created attachment 299893
  --> https://bugzilla.kernel.org/attachment.cgi?id=299893&action=edit
dmesg p8z68-v lx

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #184 from Vladdrako (vladdrako007@gmail.com) ---
No changes with the latest patch on old ASUS P8Z68-V LX. (sorry for post
spamming, newbie here) Kernel 5.15.2 Manjaro.
Attached DSDT dump and dmesg.

[   11.103782] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
[   11.103790] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\_GPE.HWRE) (20210730/utaddress-204)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #185 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
(In reply to Denis Pauk from comment #181)
> Created attachment 299887 [details]
> Add X570-I mutex
> 
> Could you check with updated patch?  

This patch is suitable for 5.16 rc3 right?

Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
1 out of 1 hunk ignored -- saving rejects to file drivers/hwmon/Kconfig.rej
73 out of 83 hunks FAILED -- saving rejects to file drivers/hwmon/nct6775.c.rej
error: Bad exit status from /var/tmp/rpm-tmp.HxCCT9 (%prep)
    Bad exit status from /var/tmp/rpm-tmp.HxCCT9 (%prep)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #186 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Mikhail from comment #185)
> (In reply to Denis Pauk from comment #181)
> > Created attachment 299887 [details]
> > Add X570-I mutex
> > 
> > Could you check with updated patch?  
> 
> This patch is suitable for 5.16 rc3 right?
> 
> Reversed (or previously applied) patch detected!  Assume -R? [n] 
> Apply anyway? [n] 
> 1 out of 1 hunk ignored -- saving rejects to file drivers/hwmon/Kconfig.rej
> 73 out of 83 hunks FAILED -- saving rejects to file
> drivers/hwmon/nct6775.c.rej
> error: Bad exit status from /var/tmp/rpm-tmp.HxCCT9 (%prep)
>     Bad exit status from /var/tmp/rpm-tmp.HxCCT9 (%prep)

Patch is based on stable v5.15 kernel version. Could you check with v5.15
kernel version from kernel.org.

(In reply to Vladdrako from comment #184)
> No changes with the latest patch on old ASUS P8Z68-V LX. (sorry for post
> spamming, newbie here) Kernel 5.15.2 Manjaro.
> Attached DSDT dump and dmesg.
> 
> [   11.103782] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
> [   11.103790] ACPI Warning: SystemIO range
> 0x0000000000000295-0x0000000000000296 conflicts with OpRegion
> 0x0000000000000290-0x0000000000000299 (\_GPE.HWRE) (20210730/utaddress-204)

P8Z68-V is not in the list of supported boards, could you try add it to the
list (asus_wmi_info_table)? 

If it does not help, could you attach dump of your bios? (acpidump -b -n DSDT).
I  assume that bios does not support WMI methods from that patch and need to
search fully different workaround.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #187 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
(In reply to Denis Pauk from comment #186)
> Patch is based on stable v5.15 kernel version. Could you check with v5.15
> kernel version from kernel.org.
> 

Hmmm...

Depmod failure
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-5.15.6-200.fc35.x86_64/./lib/modules/5.15.6-200.fc35.x86_64+debug/kernel/drivers/hwmon/nct6775.ko
needs unknown symbol wmi_evaluate_method

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #188 from Vladdrako (vladdrako007@gmail.com) ---
> P8Z68-V is not in the list of supported boards, could you try add it to the
> list (asus_wmi_info_table)? 

Added DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V LX", NULL),
Nothing changed.

> If it does not help, could you attach dump of your bios? (acpidump -b -n
> DSDT). I  assume that bios does not support WMI methods from that patch and
> need to search fully different workaround.

Here dump from CH341A https://www.upload.ee/files/13692045/P8Z68-V_LX.Bin.html

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Michael Altizer (michael@theoddone.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael@theoddone.net

--- Comment #189 from Michael Altizer (michael@theoddone.net) ---
Probably not the best place to put this, but I can confirm that this patch
appears to work on my new ASUS motherboard after updating the asus_wmi_boards
table with its board name ("ROG STRIX B550-A GAMING" - it's just a B550-F with
a different color scheme).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #190 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
Created attachment 299921
  --> https://bugzilla.kernel.org/attachment.cgi?id=299921&action=edit
Photo of FANs indication in BIOS (ROG STRIX X570-I GAMING) (

(In reply to Denis Pauk from comment #186)
> Patch is based on stable v5.15 kernel version. Could you check with v5.15
> kernel version from kernel.org.

Thanks, I beginning see CPU FAN RPM.

$ sensors
iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:        +55.0°C  

amdgpu-pci-0b00
Adapter: PCI adapter
vddgfx:      775.00 mV 
fan1:           0 RPM  (min =    0 RPM, max = 3300 RPM)
edge:         +52.0°C  (crit = +100.0°C, hyst = -273.1°C)
                       (emerg = +105.0°C)
junction:     +54.0°C  (crit = +110.0°C, hyst = -273.1°C)
                       (emerg = +115.0°C)
mem:          +56.0°C  (crit = +100.0°C, hyst = -273.1°C)
                       (emerg = +105.0°C)
power1:       15.00 W  (cap = 255.00 W)

nvme-pci-0100
Adapter: PCI adapter
Composite:    +52.9°C  

hidpp_battery_0-hid-3-9
Adapter: HID adapter
in0:           4.06 V  

nct6798-isa-0290
Adapter: ISA adapter
in0:                      976.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.41 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.36 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                      992.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      656.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      424.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.41 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.36 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      912.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     328.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     544.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.04 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     464.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     368.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                        0 RPM  (min =    0 RPM)
fan2:                      847 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +46.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +48.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +66.5°C    sensor = thermistor
AUXTIN1:                   +46.0°C    sensor = thermistor
AUXTIN2:                   +21.0°C    sensor = thermistor
AUXTIN3:                   +67.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +53.0°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +63.4°C  
Tccd1:        +53.8°C  
Tccd2:        +48.0°C  

ucsi_source_psy_0_00081-i2c-0-08
Adapter: Synopsys DesignWare I2C adapter
in0:           0.00 V  (min =  +0.00 V, max =  +0.00 V)
curr1:         0.00 A  (max =  +0.00 A)

For unknown reason  RPM of PCH FAN and RPM of HS FAN which displayed in BIOS
didn't reading by driver. It's normal?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #191 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Mikhail from comment #190)

> For unknown reason  RPM of PCH FAN and RPM of HS FAN which displayed in BIOS
> didn't reading by driver. It's normal?

That's because those sensors are read from another chip, the ACPI EC. You need
to add your board to either asus_emi_ec_sensors driver in kernel 5.16 or to not
yet mainlined new iteration of that driver which is still at Github [1]. That
should be pretty straightforward now for your board.

[1] https://github.com/zeule/asus-ec-sensors

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #192 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Vladdrako from comment #184)
> No changes with the latest patch on old ASUS P8Z68-V LX. (sorry for post
> spamming, newbie here) Kernel 5.15.2 Manjaro.
> Attached DSDT dump and dmesg.

(In reply to Vladdrako from comment #188)
> > P8Z68-V is not in the list of supported boards, could you try add it to the
> > list (asus_wmi_info_table)? 
> 
> Added DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V LX", NULL),
> Nothing changed.
> 

I am afraid "P8Z68-V LX" will be unsupported. I don't see any Acquire locks in
your dsdl related to 0x0290 region and all calls made direct operations with
superio chip. You can try with DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V LX",
&acpi_board_LPCB_MUTEX), But I am not sure that it will lock correct mutex or
be safe. 

@Eugene Shalygin Could you correct me if I have missed something?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #193 from Vladdrako (vladdrako007@gmail.com) ---
(In reply to Denis Pauk from comment #192)
> You can try with DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V
> LX", &acpi_board_LPCB_MUTEX), But I am not sure that it will lock correct
> mutex or be safe.

drivers/hwmon/nct6775.c:5443:56: error: «acpi_board_LPCB_MUTEX» undeclared here
(not in a function)
 5443 |         DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V LX",
&acpi_board_LPCB_MUTEX),
      |                                                       
^~~~~~~~~~~~~~~~~~~~~
drivers/hwmon/nct6775.c:5411:24: note: in expansion of macro
«DMI_EXACT_MATCH_ASUS_BOARD_NAME»
 5411 |         .driver_data = info,                                           
        \
      |                        ^~~~

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #299887|0                           |1
        is obsolete|                            |

--- Comment #194 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 299975
  --> https://bugzilla.kernel.org/attachment.cgi?id=299975&action=edit
Add support for access via Asus WMI to nct6775 (2021.12.09)

(In reply to Vladdrako from comment #193)
> (In reply to Denis Pauk from comment #192)
> > You can try with DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V
> > LX", &acpi_board_LPCB_MUTEX), But I am not sure that it will lock correct
> > mutex or be safe.
> 
> drivers/hwmon/nct6775.c:5443:56: error: «acpi_board_LPCB_MUTEX» undeclared
> here (not in a function)
>  5443 |         DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V LX",
> &acpi_board_LPCB_MUTEX),
>       |                                                       
> ^~~~~~~~~~~~~~~~~~~~~
> drivers/hwmon/nct6775.c:5411:24: note: in expansion of macro
> «DMI_EXACT_MATCH_ASUS_BOARD_NAME»
>  5411 |         .driver_data = info,                                        
> \
>       |                        ^~~~

Could you check with updated patch?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Jason Oickle (jason@joickle.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason@joickle.com

--- Comment #196 from Jason Oickle (jason@joickle.com) ---
I've been using the oct 10th version of this patch on 5.15 manjaro for a few
weeks without issues. Amazing work by Denis and everyone else involved!

I was just wondering if the patch is included in the 5.16 kernel or does it
still need to be patched manually?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #197 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Denis Pauk from comment #192)

> @Eugene Shalygin Could you correct me if I have missed something?

Isn't the \_SB_.PCI0.LPCB.SIO1.MUT0 mutex, referenced by
\_SB_.PCI0.LPCB.SIO1.ENFG() / \_SB_.PCI0.LPCB.SIO1.EXFG(), the one we are
looking for?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #198 from Vladdrako (vladdrako007@gmail.com) ---
@Denis Pauk
Fixed by replacing DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."), 
\ -> "ASUSTeK Computer INC."
sudo dmidecode -t 2
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.6 present.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: ASUSTeK Computer INC.
        Product Name: P8Z68-V LX
        Version: Rev X.0x
        Serial Number: MB-1234567890
        Asset Tag: To be filled by O.E.M.
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis: To be filled by O.E.M.
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0

sudo dmesg | grep ACPI
[sudo] пароль для vladdrako: 
[    0.000000] ACPI: OSL: Static SSDT installation disabled
[    0.000000] BIOS-e820: [mem 0x00000000ce941000-0x00000000ceb94fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000ceb95000-0x00000000ceba1fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000ceba2000-0x00000000cebc0fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000cebc1000-0x00000000cebc5fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000cebc6000-0x00000000cec08fff] ACPI NVS
[    0.000000] efi: ACPI=0xceb95000 ACPI 2.0=0xceb95000 SMBIOS=0xce425f98 
[    0.012426] ACPI: SSDT ACPI table found in initrd
[kernel/firmware/acpi/ssdt1.aml][0x414]
[    0.012430] ACPI: SSDT ACPI table found in initrd
[kernel/firmware/acpi/ssdt2.aml][0xb05]
[    0.012432] ACPI: SSDT ACPI table found in initrd
[kernel/firmware/acpi/ssdt3.aml][0x2f4]
[    0.012434] ACPI: SSDT ACPI table found in initrd
[kernel/firmware/acpi/ssdt4.aml][0x87b]
[    0.012436] ACPI: SSDT ACPI table found in initrd
[kernel/firmware/acpi/ssdt5.aml][0x3aa]
[    0.012438] ACPI: SSDT ACPI table found in initrd
[kernel/firmware/acpi/ssdt6.aml][0x18a]
[    0.012439] ACPI: SSDT ACPI table found in initrd
[kernel/firmware/acpi/ssdt7.aml][0x18a]
[    0.012460] modified: [mem 0x00000000ce14e000-0x00000000ce150145] ACPI data
[    0.012470] modified: [mem 0x00000000ce941000-0x00000000ceb94fff] ACPI NVS
[    0.012472] modified: [mem 0x00000000ceb95000-0x00000000ceba1fff] ACPI data
[    0.012473] modified: [mem 0x00000000ceba2000-0x00000000cebc0fff] ACPI NVS
[    0.012475] modified: [mem 0x00000000cebc1000-0x00000000cebc5fff] ACPI data
[    0.012476] modified: [mem 0x00000000cebc6000-0x00000000cec08fff] ACPI NVS
[    0.012497] ACPI: Early table checksum verification disabled
[    0.012500] ACPI: RSDP 0x00000000CEB95000 000024 (v02 ALASKA)
[    0.012503] ACPI: XSDT 0x00000000CEB95078 00006C (v01 ALASKA A M I   
01072009 AMI  00010013)
[    0.012512] ACPI: FACP 0x00000000CEB9F930 0000F4 (v04 ALASKA A M I   
01072009 AMI  00010013)
[    0.012520] ACPI: DSDT 0x00000000CEB95180 00A7B0 (v02 ALASKA A M I   
00000015 INTL 20051117)
[    0.012525] ACPI: FACS 0x00000000CEBBFF80 000040
[    0.012530] ACPI: APIC 0x00000000CEB9FA28 000072 (v03 ALASKA A M I   
01072009 AMI  00010013)
[    0.012536] ACPI: MCFG 0x00000000CEB9FAA0 00003C (v01 ALASKA A M I   
01072009 MSFT 00000097)
[    0.012541] ACPI: HPET 0x00000000CEB9FAE0 000038 (v01 ALASKA A M I   
01072009 AMI. 00000005)
[    0.012544] ACPI: Ignoring installation of SSDT at 00000000CEB9FB18
[    0.012546] ACPI: Ignoring installation of SSDT at 00000000CEB9FE88
[    0.012548] ACPI: Ignoring installation of SSDT at 00000000CEBA0838
[    0.012553] ACPI: DMAR 0x00000000CEBA12D0 0000A8 (v01 INTEL  SNB     
00000001 INTL 00000001)
[    0.012558] ACPI: BGRT 0x00000000CEBA13D0 000038 (v00 ALASKA A M I   
01072009 AMI  00010013)
[    0.012561] ACPI: Reserving FACP table memory at [mem 0xceb9f930-0xceb9fa23]
[    0.012562] ACPI: Reserving DSDT table memory at [mem 0xceb95180-0xceb9f92f]
[    0.012563] ACPI: Reserving FACS table memory at [mem 0xcebbff80-0xcebbffbf]
[    0.012564] ACPI: Reserving APIC table memory at [mem 0xceb9fa28-0xceb9fa99]
[    0.012565] ACPI: Reserving MCFG table memory at [mem 0xceb9faa0-0xceb9fadb]
[    0.012566] ACPI: Reserving HPET table memory at [mem 0xceb9fae0-0xceb9fb17]
[    0.012567] ACPI: Reserving DMAR table memory at [mem 0xceba12d0-0xceba1377]
[    0.012568] ACPI: Reserving BGRT table memory at [mem 0xceba13d0-0xceba1407]
[    0.012572] ACPI: Table Upgrade: install [SSDT- PmRef- Cpu0Ist]
[    0.012574] ACPI: Ignoring installation of SSDT at 00000000CE14E000
[    0.012576] ACPI: Table Upgrade: install [SSDT- PmRef-   CpuPm]
[    0.012577] ACPI: Ignoring installation of SSDT at 00000000CE14E414
[    0.012579] ACPI: Table Upgrade: install [SSDT-SataRe-SataTabl]
[    0.012581] ACPI: Ignoring installation of SSDT at 00000000CE14EF19
[    0.012582] ACPI: Table Upgrade: install [SSDT- PmRef- Cpu0Cst]
[    0.012584] ACPI: Ignoring installation of SSDT at 00000000CE14F20D
[    0.012585] ACPI: Table Upgrade: install [SSDT- PmRef-   ApIst]
[    0.012587] ACPI: Ignoring installation of SSDT at 00000000CE14FA88
[    0.012589] ACPI: Table Upgrade: install [SSDT- PmRef-   ApCst]
[    0.012590] ACPI: Ignoring installation of SSDT at 00000000CE14FE32
[    0.012592] ACPI: Table Upgrade: install [SSDT- PmRef-   ApCst]
[    0.012593] ACPI: Ignoring installation of SSDT at 00000000CE14FFBC
[    0.042572] ACPI: PM-Timer IO Port: 0x408
[    0.042580] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.042594] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.042595] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.042599] ACPI: Using ACPI (MADT) for SMP configuration information
[    0.042600] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.122119] ACPI: Core revision 20210730
[    0.166568] ACPI: PM: Registering ACPI NVS region [mem
0xce941000-0xceb94fff] (2441216 bytes)
[    0.166568] ACPI: PM: Registering ACPI NVS region [mem
0xceba2000-0xcebc0fff] (126976 bytes)
[    0.166568] ACPI: PM: Registering ACPI NVS region [mem
0xcebc6000-0xcec08fff] (274432 bytes)
[    0.166581] ACPI FADT declares the system doesn't support PCIe ASPM, so
disable it
[    0.166581] ACPI: bus type PCI registered
[    0.166581] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.169728] ACPI: Added _OSI(Module Device)
[    0.169728] ACPI: Added _OSI(Processor Device)
[    0.169728] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.169728] ACPI: Added _OSI(Processor Aggregator Device)
[    0.169728] ACPI: Added _OSI(Linux-Dell-Video)
[    0.169728] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[    0.169728] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[    0.177081] ACPI: 1 ACPI AML tables successfully acquired and loaded
[    0.178274] ACPI: EC: EC started
[    0.178275] ACPI: EC: interrupt blocked
[    0.178279] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    0.178281] ACPI: \_SB_.PCI0.LPCB.EC0_: Boot DSDT EC used to handle
transactions
[    0.178283] ACPI: Interpreter enabled
[    0.178298] ACPI: PM: (supports S0 S5)
[    0.178299] ACPI: Using IOAPIC for interrupt routing
[    0.178330] PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
[    0.178545] ACPI: Enabled 10 GPEs in block 00 to 3F
[    0.185721] ACPI: PM: Power Resource [FN00]
[    0.185797] ACPI: PM: Power Resource [FN01]
[    0.185874] ACPI: PM: Power Resource [FN02]
[    0.185948] ACPI: PM: Power Resource [FN03]
[    0.186023] ACPI: PM: Power Resource [FN04]
[    0.186715] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e])
[    0.193940] ACPI: PCI: Interrupt link LNKA configured for IRQ 11
[    0.194009] ACPI: PCI: Interrupt link LNKB configured for IRQ 3
[    0.194076] ACPI: PCI: Interrupt link LNKC configured for IRQ 4
[    0.194143] ACPI: PCI: Interrupt link LNKD configured for IRQ 5
[    0.194209] ACPI: PCI: Interrupt link LNKE configured for IRQ 0
[    0.194210] ACPI: PCI: Interrupt link LNKE disabled
[    0.194276] ACPI: PCI: Interrupt link LNKF configured for IRQ 10
[    0.194342] ACPI: PCI: Interrupt link LNKG configured for IRQ 0
[    0.194343] ACPI: PCI: Interrupt link LNKG disabled
[    0.194409] ACPI: PCI: Interrupt link LNKH configured for IRQ 11
[    0.194710] ACPI: EC: interrupt unblocked
[    0.194711] ACPI: EC: event unblocked
[    0.194716] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    0.194717] ACPI: EC: GPE=0x18
[    0.194719] ACPI: \_SB_.PCI0.LPCB.EC0_: Boot DSDT EC initialization complete
[    0.194720] ACPI: \_SB_.PCI0.LPCB.EC0_: EC: Used to handle transactions and
events
[    0.194782] ACPI: bus type USB registered
[    0.194782] PCI: Using ACPI for IRQ routing
[    0.207295] pnp: PnP ACPI init
[    0.208360] pnp: PnP ACPI: found 8 devices
[    0.378928] ACPI: button: Power Button [PWRB]
[    0.379132] ACPI: button: Power Button [PWRF]
[    0.379837] ACPI: thermal: Thermal Zone [TZ00] (28 C)
[    0.380112] ACPI: thermal: Thermal Zone [TZ01] (30 C)
[    5.069363] ACPI Warning: SystemIO range
0x0000000000000428-0x000000000000042F conflicts with OpRegion
0x0000000000000400-0x000000000000047F (\PMIO) (20210730/utaddress-204)
[    5.069371] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[    5.069374] ACPI Warning: SystemIO range
0x0000000000000540-0x000000000000054F conflicts with OpRegion
0x0000000000000500-0x0000000000000563 (\GPIO) (20210730/utaddress-204)
[    5.069377] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[    5.069378] ACPI Warning: SystemIO range
0x0000000000000530-0x000000000000053F conflicts with OpRegion
0x0000000000000500-0x0000000000000563 (\GPIO) (20210730/utaddress-204)
[    5.069381] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[    5.069382] ACPI Warning: SystemIO range
0x0000000000000500-0x000000000000052F conflicts with OpRegion
0x0000000000000500-0x000000000000050F (\_GPE.GPIO) (20210730/utaddress-204)
[    5.069384] ACPI Warning: SystemIO range
0x0000000000000500-0x000000000000052F conflicts with OpRegion
0x0000000000000500-0x0000000000000563 (\GPIO) (20210730/utaddress-204)
[    5.069386] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[   11.270149] ACPI: video: Video Device [GFX0] (multi-head: yes  rom: no 
post: no)
sudo dmesg | grep nct6775
[    6.082896] nct6775: Can't read chip ID by Asus WMI.
[    6.083246] nct6775: Using Asus WMI mutex: \_SB_.PCI0.LPCB.SIO1.MUT0
[    6.083277] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
[    6.083315] nct6775: i2c have not found
sensors                                                                        
                                                                               
   ✔ 
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +38.0°C  (high = +80.0°C, crit = +99.0°C)
Core 0:        +38.0°C  (high = +80.0°C, crit = +99.0°C)
Core 1:        +37.0°C  (high = +80.0°C, crit = +99.0°C)
Core 2:        +37.0°C  (high = +80.0°C, crit = +99.0°C)
Core 3:        +31.0°C  (high = +80.0°C, crit = +99.0°C)

nct6776-isa-0290
Adapter: ISA adapter
Vcore:         944.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:             1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
AVCC:            3.41 V  (min =  +2.98 V, max =  +3.63 V)
+3.3V:           3.41 V  (min =  +2.98 V, max =  +3.63 V)
in4:             1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:             2.04 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:           824.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
3VSB:            3.41 V  (min =  +2.98 V, max =  +3.63 V)
Vbat:            3.38 V  (min =  +2.70 V, max =  +3.63 V)
fan1:             0 RPM  (min =    0 RPM)
fan2:           853 RPM  (min =    0 RPM)
fan3:             0 RPM  (min =    0 RPM)
fan4:             0 RPM  (min =    0 RPM)
fan5:             0 RPM  (min =    0 RPM)
SYSTIN:         +26.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM  sensor =
thermistor
CPUTIN:         +91.0°C  (high = +81.0°C, hyst = +76.0°C)  sensor = thermistor
AUXTIN:         +63.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
PECI Agent 0:   +36.0°C  (high = +80.0°C, hyst = +75.0°C)
                         (crit = +99.0°C)
PCH_CHIP_TEMP:   +0.0°C  
PCH_CPU_TEMP:    +0.0°C  
PCH_MCH_TEMP:    +0.0°C  
intrusion0:    ALARM
intrusion1:    ALARM
beep_enable:   disabled

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +27.8°C  (crit = +105.0°C)
temp2:        +29.8°C  (crit = +105.0°C)

nvme-pci-0200
Adapter: PCI adapter
Composite:    +25.9°C  (low  =  -0.1°C, high = +69.8°C)
                       (crit = +84.8°C)
ERROR: Can't get value of subfeature temp2_min: I/O error
ERROR: Can't get value of subfeature temp2_max: I/O error
Sensor 1:     +35.9°C  (low  =  +0.0°C, high =  +0.0°C)

Now works as expected. Thanks for your work! Sadly, nobody wants to fix
conflicts with lpc_ich/gpio_ich drivers, so I will blacklist them :)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #299975|0                           |1
        is obsolete|                            |

--- Comment #199 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 300029
  --> https://bugzilla.kernel.org/attachment.cgi?id=300029&action=edit
Asus WMI for nct6775 v5.15 base (2021.12.14)

(In reply to Vladdrako from comment #198)
> @Denis Pauk
> Fixed by replacing DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER
> INC."),       \ -> "ASUSTeK Computer INC."

Could check with updated patch?

(In reply to Jason Oickle from comment #196)
> I've been using the oct 10th version of this patch on 5.15 manjaro for a few
> weeks without issues. Amazing work by Denis and everyone else involved!
> 
> I was just wondering if the patch is included in the 5.16 kernel or does it
> still need to be patched manually?

Thank you.

v5.16(nct6775) will have support of:
* "ProArt X570-CREATOR WIFI",
* "Pro WS X570-ACE",
* "PRIME B360-PLUS",
* "PRIME B460-PLUS",
* "PRIME X570-PRO",
* "ROG CROSSHAIR VIII DARK HERO",
* "ROG CROSSHAIR VIII FORMULA",
* "ROG CROSSHAIR VIII HERO",
* "ROG CROSSHAIR VIII IMPACT",
* "ROG STRIX B550-E GAMING",
* "ROG STRIX B550-F GAMING",
* "ROG STRIX B550-F GAMING (WI-FI)",
* "ROG STRIX B550-I GAMING",
* "ROG STRIX X570-F GAMING",
* "ROG STRIX Z390-E GAMING",
* "ROG STRIX Z490-I GAMING",
* "TUF GAMING B550M-PLUS",
* "TUF GAMING B550M-PLUS (WI-FI)",
* "TUF GAMING B550-PLUS",
* "TUF GAMING B550-PRO",
* "TUF GAMING X570-PLUS",
* "TUF GAMING X570-PLUS (WI-FI)",
* "TUF GAMING X570-PRO (WI-FI)",
* "TUF GAMING Z490-PLUS",
* "TUF GAMING Z490-PLUS (WI-FI)",

v5.17(nct6775) will have support of:
* "ProArt X570-CREATOR WIFI",
* "Pro WS X570-ACE",
* "PRIME B360-PLUS",
* "PRIME B460-PLUS",
* "PRIME X570-PRO",
* "ROG CROSSHAIR VIII DARK HERO",
* "ROG CROSSHAIR VIII FORMULA",
* "ROG CROSSHAIR VIII HERO",
* "ROG CROSSHAIR VIII IMPACT",
* "ROG STRIX B550-E GAMING",
* "ROG STRIX B550-F GAMING",
* "ROG STRIX B550-F GAMING (WI-FI)",
* "ROG STRIX B550-I GAMING",
* "ROG STRIX X570-F GAMING",
* "ROG STRIX Z390-E GAMING",
* "ROG STRIX Z490-I GAMING",
* "TUF GAMING B550M-PLUS",
* "TUF GAMING B550M-PLUS (WI-FI)",
* "TUF GAMING B550-PLUS",
* "TUF GAMING B550-PRO",
* "TUF GAMING X570-PLUS",
* "TUF GAMING X570-PLUS (WI-FI)",
* "TUF GAMING X570-PRO (WI-FI)",
* "TUF GAMING Z490-PLUS",
* "TUF GAMING Z490-PLUS (WI-FI)",

v5.17(asus_wmi_ec_sensors) will have support of:
* "PRIME X570-PRO",
* "Pro WS X570-ACE",
* "ROG CROSSHAIR VIII DARK HERO",
* "ROG CROSSHAIR VIII FORMULA",
* "ROG CROSSHAIR VIII HERO",
* "ROG STRIX B550-E GAMING",
* "ROG STRIX B550-I GAMING", 
* "ROG STRIX X570-E GAMING", 

v5.17(asus_wmi_sensors) will have support (board version from 2) of:
* "PRIME X399-A",
* "PRIME X470-PRO",
* "ROG CROSSHAIR VI EXTREME",
* "ROG CROSSHAIR VI HERO",
* "ROG CROSSHAIR VI HERO (WI-FI AC)",
* "ROG CROSSHAIR VII HERO",
* "ROG CROSSHAIR VII HERO (WI-FI)",
* "ROG STRIX B450-E GAMING",
* "ROG STRIX B450-F GAMING",
* "ROG STRIX B450-I GAMING",
* "ROG STRIX X399-E GAMING",
* "ROG STRIX X470-F GAMING",
* "ROG STRIX X470-I GAMING",
* "ROG ZENITH EXTREME",
* "ROG ZENITH EXTREME ALPHA",

Support of others boards is not merged/reviewed yet.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #200 from Vladdrako (vladdrako007@gmail.com) ---
(In reply to Denis Pauk from comment #199)
> Could check with updated patch?

Works fine.

sudo dmesg | grep wmi
[    7.943237] asus_wmi: ASUS WMI generic driver loaded
[    8.052769] asus_wmi: Initialization: 0x0
[    8.052805] asus_wmi: BIOS WMI version: 0.9
[    8.052863] asus_wmi: SFUN value: 0x0
[    8.052866] eeepc-wmi eeepc-wmi: Detected ASUSWMI, use DCTS
[    8.053621] input: Eee PC WMI hotkeys as
/devices/platform/eeepc-wmi/input/input13
sudo dmesg | grep nct6775
[    8.074613] nct6775: Can't read chip ID by Asus WMI.
[    8.074982] nct6775: Using Asus WMI mutex: \_SB_.PCI0.LPCB.SIO1.MUT0
[    8.075014] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
[    8.075056] nct6775: i2c have not found
sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +37.0°C  (high = +80.0°C, crit = +99.0°C)
Core 0:        +37.0°C  (high = +80.0°C, crit = +99.0°C)
Core 1:        +36.0°C  (high = +80.0°C, crit = +99.0°C)
Core 2:        +37.0°C  (high = +80.0°C, crit = +99.0°C)
Core 3:        +31.0°C  (high = +80.0°C, crit = +99.0°C)

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +27.8°C  (crit = +105.0°C)
temp2:        +29.8°C  (crit = +105.0°C)

nct6776-isa-0290
Adapter: ISA adapter
Vcore:         944.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:             1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
AVCC:            3.41 V  (min =  +2.98 V, max =  +3.63 V)
+3.3V:           3.41 V  (min =  +2.98 V, max =  +3.63 V)
in4:             1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:             2.04 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:           832.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
3VSB:            3.42 V  (min =  +2.98 V, max =  +3.63 V)
Vbat:            3.38 V  (min =  +2.70 V, max =  +3.63 V)
fan1:             0 RPM  (min =    0 RPM)
fan2:           856 RPM  (min =    0 RPM)
fan3:             0 RPM  (min =    0 RPM)
fan4:             0 RPM  (min =    0 RPM)
fan5:             0 RPM  (min =    0 RPM)
SYSTIN:         +27.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM  sensor =
thermistor
CPUTIN:         +91.5°C  (high = +81.0°C, hyst = +76.0°C)  ALARM  sensor =
thermistor
AUXTIN:         +64.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
PECI Agent 0:   +36.0°C  (high = +80.0°C, hyst = +75.0°C)
                         (crit = +99.0°C)
PCH_CHIP_TEMP:   +0.0°C  
PCH_CPU_TEMP:    +0.0°C  
PCH_MCH_TEMP:    +0.0°C  
intrusion0:    ALARM
intrusion1:    ALARM
beep_enable:   disabled

nvme-pci-0200
Adapter: PCI adapter
Composite:    +25.9°C  (low  =  -0.1°C, high = +69.8°C)
                       (crit = +84.8°C)
ERROR: Can't get value of subfeature temp2_min: I/O error
ERROR: Can't get value of subfeature temp2_max: I/O error
Sensor 1:     +37.9°C  (low  =  +0.0°C, high =  +0.0°C)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Ivo Ivanov (logos128@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |logos128@gmail.com

--- Comment #201 from Ivo Ivanov (logos128@gmail.com) ---
Created attachment 300039
  --> https://bugzilla.kernel.org/attachment.cgi?id=300039&action=edit
0001-hwmon-nct6775-Add-support-for-ROG-MAXIMUS-X-HERO.patch

I can confirm that the sensors of Asus ROG MAXIMUS X HERO also work with the
proposed patchset. The name of the board is "ROG MAXIMUS X HERO", and needs to
use acpi_board_LPCB_MUTEX.

Attached a patch based on the Linux 5.15 branch with applied latest patchset
for nct6775 from 2021.12.14 (comment #199 from Denis Pauk).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Gregory P. Smith (greg@krypto.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |greg@krypto.org

--- Comment #202 from Gregory P. Smith (greg@krypto.org) ---
Created attachment 300125
  --> https://bugzilla.kernel.org/attachment.cgi?id=300125&action=edit
ASUS Pro B550M-C/CSM acpidump -b dsdt.dat

The "Pro B550M-C" as mentioned in #c70 also appears to need to be in a list.

$ cat /sys/class/dmi/id/board_name 
Pro B550M-C

https://www.asus.com/us/Motherboards-Components/Motherboards/CSM/Pro-B550M-C-CSM/

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #204 from Jonathan Farrugia (jonfarr87@gmail.com) ---
(In reply to Jonathan Farrugia from comment #203)
> As of Kernel 5.15, and now 5.16 too. My board no longer reads my chip either
> - nct6798.
> 
> Works fine up to Kernel 5.14.21 though.
> 
> How can I help re-adding this support back in?
> 
> Thanks

Forgot to add my board details:

cat /sys/class/dmi/id/board_name 
PRIME B550M-A

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #300029|0                           |1
        is obsolete|                            |

--- Comment #205 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 300253
  --> https://bugzilla.kernel.org/attachment.cgi?id=300253&action=edit
Asus WMI for nct6775 v5.16 base (2022.01.11)

(In reply to Jonathan Farrugia from comment #204)
> cat /sys/class/dmi/id/board_name 
> PRIME B550M-A
(In reply to Gregory P. Smith from comment #202)
> The "Pro B550M-C" as mentioned in #c70 also appears to need to be in a list.
> 
> $ cat /sys/class/dmi/id/board_name 
> Pro B550M-C
> 
> https://www.asus.com/us/Motherboards-Components/Motherboards/CSM/Pro-B550M-C-
> CSM/

Could you check with updated patch?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Aleksa Savic (savicaleksa83@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |savicaleksa83@gmail.com

--- Comment #206 from Aleksa Savic (savicaleksa83@gmail.com) ---
Hi! I've tested my ROG STRIX B450-F GAMING II with asus_wmi_sensors. Seems to
mostly work?

asus_wmi_sensors-virtual-0
Adapter: Virtual device
CPU Core Voltage:        905.00 mV 
VPP MEM Voltage:           2.54 V  
+12V Voltage:             10.25 V  
+5V Voltage:               5.15 V  
3VSB Voltage:              3.40 V  
VBAT Voltage:              3.29 V  
AVCC3 Voltage:             3.40 V  
SB 1.05V Voltage:          1.04 V  
CPU Core Voltage:          0.00 V  
CPU SOC Voltage:           0.00 V  
CPU Fan:                  795 RPM
Chassis Fan 1:            813 RPM
Chassis Fan 2:              0 RPM
Chassis Fan 3:            555 RPM
AIO Pump:                   0 RPM
Water Pump:                 0 RPM
CPU OPT:                    0 RPM
CPU Temperature:          +36.0°C  
CPU Socket Temperature:   +30.0°C  
Motherboard Temperature:  +32.0°C  
Chipset Temperature:      +36.0°C  
Tsensor 1 Temperature:   +216.0°C  
CPU VRM Temperature:       +0.0°C  
CPU VRM Output Current:    0.00 A

Not sure what's up with Tsensor1.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #207 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Aleksa Savic from comment #206)
> Not sure what's up with Tsensor1.

That's the blank value.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #208 from Aleksa Savic (savicaleksa83@gmail.com) ---
That's what I suspected, thanks for confirming. Do I need to check anything
else, is it good for addition?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #209 from Jonathan Farrugia (jonfarr87@gmail.com) ---
(In reply to Denis Pauk from comment #205)
> Created attachment 300253 [details]
> Asus WMI for nct6775 v5.16 base (2022.01.11)
> 
> (In reply to Jonathan Farrugia from comment #204)
> > cat /sys/class/dmi/id/board_name 
> > PRIME B550M-A
> (In reply to Gregory P. Smith from comment #202)
> > The "Pro B550M-C" as mentioned in #c70 also appears to need to be in a
> list.
> > 
> > $ cat /sys/class/dmi/id/board_name 
> > Pro B550M-C
> > 
> >
> https://www.asus.com/us/Motherboards-Components/Motherboards/CSM/Pro-B550M-C-
> > CSM/
> 
> Could you check with updated patch?


Just tried the patch. The chip is being detected correctly and readings are the
same as with Kernel 5.14.21.

nct6798-isa-0290
Adapter: ISA adapter
in0:                       +0.39 V  (min =  +0.00 V, max =  +1.74 V)
in1:                       +1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                       +3.44 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                       +3.33 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                       +1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                       +1.05 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                       +1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                       +3.44 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                       +3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                       +0.92 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                      +0.52 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                      +0.52 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                      +1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                      +1.00 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                      +1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                     1347 RPM  (min =    0 RPM)
fan2:                     1279 RPM  (min =    0 RPM)
fan3:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +23.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +28.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +25.5°C    sensor = thermistor
AUXTIN1:                   +23.0°C    sensor = thermistor
AUXTIN2:                   +23.0°C    sensor = thermistor
AUXTIN3:                   +26.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +28.5°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled


If I may ask, will this work be integrated into 5.16.x patches?

Thanks :)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Per Melin (kernel@melin.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kernel@melin.net

--- Comment #210 from Per Melin (kernel@melin.net) ---
One more board.

--- a/drivers/hwmon/nct6775.c
+++ b/drivers/hwmon/nct6775.c
@@ -5001,6 +5001,7 @@ static const char * const asus_wmi_boards[] = {
        "ROG STRIX X570-F GAMING",
        "ROG STRIX X570-I GAMING",
        "ROG STRIX Z390-E GAMING",
+       "ROG STRIX Z390-F GAMING",
        "ROG STRIX Z490-I GAMING",
        "TUF GAMING B550M-PLUS",
        "TUF GAMING B550M-PLUS (WI-FI)",

And it works.

[    8.534975] nct6775: Using Asus WMI to access 0xc1 chip.
[    8.535102] nct6775: Enabling hardware monitor logical device mappings.
[    8.535141] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290

nct6798-isa-0290
Adapter: ISA adapter
in0:                      648.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.36 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                        1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      176.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                        0.00 V  (min =  +0.00 V, max =  +0.00 V)
in7:                        3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.12 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      528.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     584.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     512.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.06 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     296.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     560.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                      481 RPM  (min =    0 RPM)
fan2:                      520 RPM  (min =    0 RPM)
fan3:                      435 RPM  (min =    0 RPM)
fan4:                      484 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan6:                      517 RPM  (min =    0 RPM)
fan7:                     4231 RPM  (min =    0 RPM)
SYSTIN:                    +28.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +32.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                  -128.0°C    sensor = thermistor
AUXTIN1:                   +17.0°C    sensor = thermistor
AUXTIN2:                   +25.0°C    sensor = thermistor
AUXTIN3:                   +53.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +32.5°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
intrusion0:               OK
intrusion1:               ALARM
beep_enable:              disabled

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +27.8°C  (crit = +119.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +45.0°C  (high = +86.0°C, crit = +100.0°C)
Core 0:        +32.0°C  (high = +86.0°C, crit = +100.0°C)
Core 1:        +33.0°C  (high = +86.0°C, crit = +100.0°C)
Core 2:        +33.0°C  (high = +86.0°C, crit = +100.0°C)
Core 3:        +45.0°C  (high = +86.0°C, crit = +100.0°C)
Core 4:        +32.0°C  (high = +86.0°C, crit = +100.0°C)
Core 5:        +33.0°C  (high = +86.0°C, crit = +100.0°C)
Core 6:        +33.0°C  (high = +86.0°C, crit = +100.0°C)
Core 7:        +32.0°C  (high = +86.0°C, crit = +100.0°C)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #300253|0                           |1
        is obsolete|                            |

--- Comment #212 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 300351
  --> https://bugzilla.kernel.org/attachment.cgi?id=300351&action=edit
Asus WMI for nct6775 v5.16 base (2022.01.30)

Updated patch with X570-E and Z390-F/H/I. 

Boards with possible support of i2c connection/mutex are moved to separate
section. 

Also includes patches from
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/log/?h=hwmon-next
and
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/log/?h=hwmon-for-v5.17-rc2

(In reply to Jonathan Farrugia from comment #211)
> Any idea if or when this fix will make it into a Kernel release? As of
> 5.16.3 it's still not merged.

Patch with "Pro B550M-C" will be included to 5.18 release.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #300351|0                           |1
        is obsolete|                            |

--- Comment #213 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 300389
  --> https://bugzilla.kernel.org/attachment.cgi?id=300389&action=edit
Asus WMI for nct6775 v5.16 base (2022.02.03)

Added SENSORS_ASUS_EC driver. 

Same as SENSORS_ASUS_WMI_EC but much faster.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #214 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
> Added SENSORS_ASUS_EC driver. 
> Same as SENSORS_ASUS_WMI_EC but much faster.

BTW, the WMI code works awfully slow in most of the kernel configurations I
tried, but with my custom kernel (Gentoo) it works OK. When I use a Fedora
kernel config in the same environment, EC operations via WMI become slow. I
tried to unload various modules but to date do not know what slows down the
kernel. It would be great to find that out.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #215 from Jaap de Haan (jaap.dehaan@freenet.de) ---
My Board happens to report "PRIME X570-P" instead of "PRIME X570-PRO" (what I
saw in the source code)...


> sudo dmidecode -t 2
> # dmidecode 3.2
> Getting SMBIOS data from sysfs.
> SMBIOS 3.3.0 present.
> # SMBIOS implementations newer than version 3.2.0 are not
> # fully supported by this version of dmidecode.
> 
> Handle 0x0002, DMI type 2, 15 bytes
> Base Board Information
>       Manufacturer: ASUSTeK COMPUTER INC.
>       Product Name: PRIME X570-P
>       Version: Rev X.0x
>       Serial Number: 200569769502586
>       Asset Tag: Default string
>       Features:
>               Board is a hosting board
>               Board is replaceable
>       Location In Chassis: Default string
>       Chassis Handle: 0x0003
>       Type: Motherboard
>       Contained Object Handles: 0

I have the latest available bios installed for my board.

> BIOS Information
>         Vendor: American Megatrends Inc.
>         Version: 4021
>         Release Date: 08/09/2021
>         Address: 0xF0000
>         Runtime Size: 64 kB
>         ROM Size: 16 MB
>         Characteristics:
>                 PCI is supported
>                 APM is supported
>                 BIOS is upgradeable
>                 BIOS shadowing is allowed
>                 Boot from CD is supported
>                 Selectable boot is supported
>                 BIOS ROM is socketed
>                 EDD is supported
>                 5.25"/1.2 MB floppy services are supported (int 13h)
>                 3.5"/720 kB floppy services are supported (int 13h)
>                 3.5"/2.88 MB floppy services are supported (int 13h)
>                 Print screen service is supported (int 5h)
>                 8042 keyboard services are supported (int 9h)
>                 Serial services are supported (int 14h)
>                 Printer services are supported (int 17h)
>                 ACPI is supported
>                 USB legacy is supported
>                 BIOS boot specification is supported
>                 Targeted content distribution is supported
>                 UEFI is supported
>         BIOS Revision: 5.17

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #216 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Jaap de Haan from comment #215)
> My Board happens to report "PRIME X570-P" instead of "PRIME X570-PRO" (what
> I saw in the source code)...

They look like two distinct models:

https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-X570-PRO/

https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-X570-P/

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #300389|0                           |1
        is obsolete|                            |

--- Comment #218 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 300417
  --> https://bugzilla.kernel.org/attachment.cgi?id=300417&action=edit
Asus WMI for nct6775 v5.16 base (2022.02.08)

(In reply to Eugene Shalygin from comment #216)
> (In reply to Jaap de Haan from comment #215)
> > My Board happens to report "PRIME X570-P" instead of "PRIME X570-PRO" (what
> > I saw in the source code)...
> 
> They look like two distinct models:
> 
> https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-X570-
> PRO/
> 
> https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-X570-P/

Updated version of patch with asus-ec-sensors CPU core voltage patch from
Eugene Shalygin and additional support in nct6775 module for
* PRIME X570-P,
* ROG STRIX B550-F GAMING WIFI II,
* ROG STRIX B550-XE GAMING (WI-FI),
* ROG STRIX X570-E GAMING,
* ROG STRIX Z390-F GAMING,
* ROG STRIX Z390-H GAMING,
* ROG STRIX Z390-I GAMING,
* ROG STRIX Z490-A GAMING,
* ROG STRIX Z490-E GAMING,
* ROG STRIX Z490-F GAMING,
* ROG STRIX Z490-G GAMING,
* ROG STRIX Z490-G GAMING (WI-FI),
* ROG STRIX Z490-H GAMING

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Sylvain Munaut (246tnt@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |246tnt@gmail.com

--- Comment #219 from Sylvain Munaut (246tnt@gmail.com) ---
Created attachment 300478
  --> https://bugzilla.kernel.org/attachment.cgi?id=300478&action=edit
ASUS PRIME H510-K DSDT table

So, I have an ASUS PRIME H510-K motherboard and was faced with the same issue.

Just adding the motherboard in the list wasn't sufficient however. Because
although the ACPI method exist for read/write of the registers under the WMBD
method, the WMI table listing the GUID doesn't actually list that 0xBD object
so the WMI calls failed ...

I "worked around" it by runtime patching the DSDT table, but it's not exactly
user friendly ... maybe a module quirk based on model to ignore the _WDG table
and just calling WMBD directly would be better.

Anyway, just wanted to report on my experience.

I also contacted Asus and described the issue in detail, but let's face it,
there isn't a chance in hell that this is going to be fixed on their side ...

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #300417|0                           |1
        is obsolete|                            |

--- Comment #220 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 300506
  --> https://bugzilla.kernel.org/attachment.cgi?id=300506&action=edit
Asus WMI for nct6775 v5.16 base (2022.02.22)

Update code with up streamed Eugene Shalygin patches for asus_ec_sensors.

asus_wmi_ec_sensors is also updated to be in sync with asus_ec_sensors. Could
some one check with "ROG STRIX X570-F GAMING"/"ROG STRIX X570-I GAMING". 

Could someone with a such boards check?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #221 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
I use kernel 5.17 rc5 commit 5c1ee569660d.
And my M/B is "ROG STRIX X570-I GAMING".
The driver nct6775 not automatically loaded for unknown reason.
Demonstration: https://youtu.be/NyTqxwshE-s

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #222 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
Denis it's a normal that nct6775 driver not automatically loaded?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Emmanuel Mayor (emayor@live.com.ar) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |emayor@live.com.ar

--- Comment #223 from Emmanuel Mayor (emayor@live.com.ar) ---
Same issue with Rog Strix Z370-H Gaming, which has Nuvoton NCT6793D

Kernel version: 5.16.11-zen1-1-zen

[    2.018193] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20210930/utaddress-204)
[    2.018199] ACPI: OSL: Resource conflict; ACPI support missing from driver?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Hubert Banas (hubert.banas@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubert.banas@gmail.com

--- Comment #225 from Hubert Banas (hubert.banas@gmail.com) ---
First I would like to thank all of you who contributed to this patch. Special
thanks to Denis who took it upstream.

I have another candidate and was hoping we can have it added to the patch.

$ cat /sys/class/dmi/id/board_name
ROG STRIX X570-E GAMING WIFI II

$ dmesg
[    4.244908] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[    4.244914] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210930/utaddress-204)
[    4.244919] ACPI: OSL: Resource conflict; ACPI support missing from driver?

$ uname -a
Linux pop-os 5.16.11-76051611-generic #202202230823~1646248261~21.10~2b22243
SMP PREEMPT Wed Mar 2 20: x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="21.10"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 21.10"
VERSION_ID="21.10"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=impish
UBUNTU_CODENAME=impish
LOGO=distributor-logo-pop-os

Thank you!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #227 from Hubert Banas (hubert.banas@gmail.com) ---
Created attachment 300540
  --> https://bugzilla.kernel.org/attachment.cgi?id=300540&action=edit
DSDT dump - ROG STRIX X570-E GAMING WIFI II

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

renedis (renedis@hotmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |renedis@hotmail.com

--- Comment #228 from renedis (renedis@hotmail.com) ---
Thanks all for the effort en support. please also add:

cat /sys/class/dmi/id/board_name
PRO H410T

[    5.478347] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[    5.478351] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210331/utaddress-204)
[    5.478356] ACPI: OSL: Resource conflict; ACPI support missing from driver?

uname -a
Linux rd-nas01 5.13.0-35-generic #40-Ubuntu SMP Mon Mar 7 08:03:10 UTC 2022
x86_64 x86_64 x86_64 GNU/Linux

cat /etc/os-release
PRETTY_NAME="Ubuntu 21.10"
NAME="Ubuntu"
VERSION_ID="21.10"
VERSION="21.10 (Impish Indri)"
VERSION_CODENAME=impish
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=impish

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #229 from Hubert Banas (hubert.banas@gmail.com) ---
Would it be possible to get these new motherboard in during Linux 5.18 merge
window?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #230 from Gregory P. Smith (greg@krypto.org) ---
I hope someone works on the big picture problem: Maintaining hard coded lists
of random vendor specific strings in the kernel source code does not scale.

The only solution for anyone overlooked or unidentified is to modify a list in
the kernel source code and maintain their own fork of the distro's kernel for
years? That is unfriendly and leaves most actual users stuck.

A way to choose which settings to use at boot and/or module load time (or amend
these lists) via configuration external to the kernel (ex: parameters) would
avoid this endless "me too" string submission dance.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #300506|0                           |1
        is obsolete|                            |

--- Comment #231 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 300687
  --> https://bugzilla.kernel.org/attachment.cgi?id=300687&action=edit
Asus WMI for nct6775 v5.17 base (2022.04.03)

(In reply to renedis from comment #228)
> Thanks all for the effort en support. please also add:
> 
> cat /sys/class/dmi/id/board_name
> PRO H410T

(In reply to Hubert Banas from comment #225)
> First I would like to thank all of you who contributed to this patch.
> Special thanks to Denis who took it upstream.
> 
> I have another candidate and was hoping we can have it added to the patch.
> 
> $ cat /sys/class/dmi/id/board_name
> ROG STRIX X570-E GAMING WIFI II

Could you please recheck with new patch?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #232 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to renedis from comment #228)
> Thanks all for the effort en support. please also add:
> 
> cat /sys/class/dmi/id/board_name
> PRO H410T

Could you please share dsdt dump? (acpidump -b -n DSDT)

(In reply to Hubert Banas from comment #229)
> Would it be possible to get these new motherboard in during Linux 5.18 merge
> window?

It can be part of 5.19+ if patch will be accepted before start of the new merge
window. (I have not sent patch yet.)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #233 from Hubert Banas (hubert.banas@gmail.com) ---
(In reply to Denis Pauk from comment #232)

> (In reply to Hubert Banas from comment #229)
> > Would it be possible to get these new motherboard in during Linux 5.18
> merge
> > window?
> 
> It can be part of 5.19+ if patch will be accepted before start of the new
> merge window. (I have not sent patch yet.)

Sounds good. Thank you.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Dmitrii Levchenko (e_dimas@rambler.ru) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |e_dimas@rambler.ru

--- Comment #234 from Dmitrii Levchenko (e_dimas@rambler.ru) ---
Thanks all for the effort.
Please also add:

$ cat /sys/class/dmi/id/board_name
PRIME H410M-R

$ dmesg
[ 1685.886012] nct6775: Enabling hardware monitor logical device mappings.
[ 1685.886040] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[ 1685.886044] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210730/utaddress-213)
[ 1685.886048] ACPI: OSL: Resource conflict; ACPI support missing from driver?

$ uname -a
Linux localhost.localdomain 5.14.21-150400.19-default #1 SMP PREEMPT_DYNAMIC
Wed Apr 20 08:32:52 UTC 2022 (d6fb753) x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.4 Beta"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.4"
PRETTY_NAME="openSUSE Leap 15.4 Beta"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.4"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap"
LOGO="distributor-logo-Leap"

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #300687|0                           |1
        is obsolete|                            |

--- Comment #235 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 300872
  --> https://bugzilla.kernel.org/attachment.cgi?id=300872&action=edit
Asus WMI for nct6775 v5.17 base (2022.05.03)

Added support by WMI for:
* PRO H410T
* PRIME H410M-R
* ROG STRIX X570-E GAMING WIFI II

By ACPI lock (will not be upstreamed):
* ROG STRIX Z370-H GAMING

Code is fully untested.

(In reply to Dmitrii Levchenko from comment #234)
> Thanks all for the effort.
> Please also add:
> 
> $ cat /sys/class/dmi/id/board_name
> PRIME H410M-R
(In reply to Hubert Banas from comment #233)
> > 
> > It can be part of 5.19+ if patch will be accepted before start of the new
> > merge window. (I have not sent patch yet.)
> 
> Sounds good. Thank you.

Upstream contains rework of nct6775, I have applied all commits but can't check
code with real hardware for now. If everything works for you, i will send patch
to updated with new boards.

(In reply to Emmanuel Mayor from comment #223)
> Same issue with Rog Strix Z370-H Gaming, which has Nuvoton NCT6793D
> 
DSDT does not have required WMI interface, board support can be implemented
only by direct lock of ACPI mutex.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #236 from renedis (renedis@hotmail.com) ---
Created attachment 300905
  --> https://bugzilla.kernel.org/attachment.cgi?id=300905&action=edit
acpidump -b -n DSDT for H410T

(In reply to Denis Pauk from comment #232)
> (In reply to renedis from comment #228)
> > Thanks all for the effort en support. please also add:
> > 
> > cat /sys/class/dmi/id/board_name
> > PRO H410T
> 
> Could you please share dsdt dump? (acpidump -b -n DSDT)

Sorry for the late reply.
There you go, see attached file.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #237 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to renedis from comment #236)
> Created attachment 300905 [details]
> acpidump -b -n DSDT for H410T
> 
> (In reply to Denis Pauk from comment #232)
> > (In reply to renedis from comment #228)
> > > Thanks all for the effort en support. please also add:
> > > 
> > > cat /sys/class/dmi/id/board_name
> > > PRO H410T
> > 
> > Could you please share dsdt dump? (acpidump -b -n DSDT)
> 
> Sorry for the late reply.
> There you go, see attached file.

Thank you, could you please check patch attached in #235?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Sven Arvidsson (sa@whiz.se) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sa@whiz.se

--- Comment #238 from Sven Arvidsson (sa@whiz.se) ---
Created attachment 300932
  --> https://bugzilla.kernel.org/attachment.cgi?id=300932&action=edit
Z170M-PLUS dsdt dump

Hi,

Can the Asus Z170M-PLUS be supported by this effort too?

cat /sys/class/dmi/id/board_name
Z170M-PLUS

[May11 11:46] nct6775: Enabling hardware monitor logical device mappings.
[  +0.000028] nct6775: Found NCT6793D or compatible chip at 0x2e:0x290
[  +0.000004] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20211217/utaddress-204)
[  +0.000004] ACPI: OSL: Resource conflict; ACPI support missing from driver?

dsdt dump is attached.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Rob Miller (rob@janerob.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rob@janerob.com

--- Comment #239 from Rob Miller (rob@janerob.com) ---
Created attachment 300958
  --> https://bugzilla.kernel.org/attachment.cgi?id=300958&action=edit
Asus Z170-DELUXE dump

Thank you for continued work, herewith details for another Asus Z170 board:

$ cat /sys/class/dmi/id/board_name
Z170-DELUXE

$ cat /proc/version
Linux version 5.17.7-051707-generic (kernel@gloin) (gcc (Ubuntu
11.3.0-1ubuntu1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #202205121146
SMP PREEMPT Thu May 12 13:20:51 UTC 2022

still needs `acpi_enforce_resources=lax` for sensors to work

dmesg:
[    3.565498] nct6775: Found NCT6793D or compatible chip at 0x2e:0x290
[    3.566379] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20211217/utaddress-204)
[    3.568047] ACPI: OSL: Resource conflict; ACPI support missing from driver?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #300872|0                           |1
        is obsolete|                            |

--- Comment #240 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 300963
  --> https://bugzilla.kernel.org/attachment.cgi?id=300963&action=edit
Asus WMI for nct6775 v5.17 base (2022.05.15)

(In reply to Rob Miller from comment #239)
> Created attachment 300958 [details]
> Asus Z170-DELUXE dump

(In reply to Sven Arvidsson from comment #238)
> Created attachment 300932 [details]
> Z170M-PLUS dsdt dump

Unfortunately, your motherboard does not have any endpoints supported by
upstreamed drivers. 

Could you please try with attached patch? It provides custom lock method that
is unsupported by upstream driver.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #241 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
Denis, please answer the question.
The driver `nct6775` I should manually loaded after each boot? Or it should be
loaded automatically?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #242 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Mikhail from comment #241)
> Denis, please answer the question.
> The driver `nct6775` I should manually loaded after each boot? Or it should
> be loaded automatically?

Driver should be automatically loaded on next reboot after modules_install. 

What do you have in dmesg after 'modprobe nct6775' or 'insmod
<path>/nct6775.ko' ?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #243 from Mikhail (mikhail.v.gavrilov@gmail.com) ---
(In reply to Denis Pauk from comment #242)
> Driver should be automatically loaded on next reboot after modules_install. 

I expecting that default kernel package in my distro (Fedora Rawhide) already
have latest nct6775 driver. So didn't run make modules_install because it
unacceptable for a package based distribution (no one want that package based
distro turns into Slackware).

> What do you have in dmesg after 'modprobe nct6775' or 'insmod
> <path>/nct6775.ko' ?

Modprobe looks good:
# modprobe nct6775

[   95.017206] nct6775: Using Asus WMI to access 0xc1 chip.
[   95.017239] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290

Driver is loading manually without any errors and sensors become show chipset
information.

But insmod unapplicable because in Fedora all modules is compressed:
# insmod
/usr/lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz 
insmod: ERROR: could not insert module
/usr/lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz:
Unknown symbol in module

# depmod
/lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz 
depmod: ERROR: Bad version passed
/lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz

# modinfo
/lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz 
filename:      
/lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz
license:        GPL
description:    Driver for NCT6775F and compatible chips
author:         Guenter Roeck <linux@roeck-us.net>
rhelversion:    9.99
depends:        hwmon-vid,wmi
retpoline:      Y
intree:         Y
name:           nct6775
vermagic:       5.18.0-0.rc7.54.fc37.x86_64+debug SMP preempt mod_unload 
sig_id:         PKCS#7
signer:         Fedora kernel signing key
sig_key:        05:21:2C:F4:BE:27:02:E2:CE:C9:4F:8F:A6:94:3B:72:76:05:73:E1
sig_hashalgo:   sha256
signature:      A4:5D:3C:C7:5F:0F:4E:DE:D9:B5:D9:CC:8C:4A:FD:D5:9A:5A:53:F8:
                60:F8:AD:4D:93:26:31:6C:88:EF:FB:5C:96:34:FE:D1:FA:8A:15:5F:
                DE:8A:CA:02:1B:14:BB:FF:92:AE:F0:7E:98:61:8B:FD:BC:39:FA:5C:
                83:DD:1A:36:ED:E0:E7:C1:84:73:C7:1C:15:8E:50:8B:7A:10:CA:09:
                A2:CC:11:8E:D2:CF:63:94:56:A7:E4:C3:EC:19:0A:25:F6:19:B7:3C:
                1F:95:74:E6:C5:E0:B8:17:B3:C0:D0:3E:D7:93:F6:94:10:DB:17:BC:
                1D:DD:AF:EA:51:D6:A4:9B:83:F5:00:AF:96:EA:C0:E5:B2:E3:DA:97:
                5D:58:B9:6A:E5:8A:32:1A:EE:CD:17:04:6D:97:72:60:90:F2:B5:C4:
                DB:71:3A:45:FC:86:0E:1D:94:8F:98:5F:5C:C8:0E:48:99:7B:3E:BC:
                FA:07:01:2E:F8:45:E8:04:B0:A2:57:11:9B:B5:3A:C9:22:86:11:92:
                E2:5C:0D:91:7A:91:36:64:24:12:26:68:36:4F:AD:6F:C2:64:A7:DB:
                69:0E:D6:B5:A6:A2:21:BC:6F:4A:B1:6E:40:F4:33:15:8C:E4:CB:B0:
                09:B2:E7:8C:64:5A:67:30:50:05:A2:53:1D:7B:50:11:A1:25:67:5A:
                05:94:06:D7:74:D3:59:26:B0:B4:0E:72:9E:50:A7:68:E3:EC:0C:E4:
                75:26:20:33:77:0D:0A:C1:B7:29:98:D4:36:2E:E5:87:2F:9A:54:E5:
                51:13:A4:D0:A9:04:BC:48:DA:33:B7:33:08:F0:12:D9:55:03:E3:05:
                A4:0F:6A:6A:23:9D:92:A5:7E:72:BF:C3:73:FE:EF:4D:FD:2A:D2:4D:
                04:AE:77:EF:11:26:E4:AF:7F:16:8A:7B:0C:45:51:78:4B:2D:7B:3A:
                10:3D:E9:7E:19:45:8C:CA:74:A1:66:4B:EB:DC:F3:BC:DF:78:E8:EF:
                87:52:94:A6:C3:37:76:FB:3B:CE:1E:04:29:5C:AE:93:91:80:CC:57:
                8D:B5:63:E7:F8:6E:EC:5A:DE:62:56:E9:4B:18:50:20:58:A2:52:E0:
                F3:F5:DA:B2:28:9F:9C:8D:D7:FC:A8:90:67:BC:12:2D:E3:3C:57:02:
                3A:8D:B2:08:21:86:F6:D9:D2:BB:6C:39:A4:D8:B3:29:59:FC:24:00:
                64:C2:92:AA:1F:AA:33:43:9F:5F:1E:2E:95:0B:72:13:38:A2:DB:77:
                1F:00:86:78:D9:D2:AD:87:AA:9E:E4:6B:8D:80:8E:44:DC:EC:A8:92:
                02:86:3B:0F:0D:EA:4C:AD:A8:E4:50:0F
parm:           force_id:Override the detected device ID (ushort)
parm:           fan_debounce:Enable debouncing for fan RPM signal (ushort)


# uname -r
5.18.0-0.rc7.54.fc37.x86_64+debug

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #244 from Sven Arvidsson (sa@whiz.se) ---
(In reply to Denis Pauk from comment #240)
> 
> Could you please try with attached patch? It provides custom lock method
> that is unsupported by upstream driver.
Thanks for the patch and your continued work on this!

Unfortunately, there's no difference on my system after applying the patch. I
get the same warnings about a resource conflict and missing ACPI support.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #300963|0                           |1
        is obsolete|                            |

--- Comment #245 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 301030
  --> https://bugzilla.kernel.org/attachment.cgi?id=301030&action=edit
Asus WMI for nct6775 v5.18 base (2022.05.24)

(In reply to Sven Arvidsson from comment #244)
> (In reply to Denis Pauk from comment #240)
> > 
> > Could you please try with attached patch? It provides custom lock method
> > that is unsupported by upstream driver.
> Thanks for the patch and your continued work on this!
> 
> Unfortunately, there's no difference on my system after applying the patch.
> I get the same warnings about a resource conflict and missing ACPI support.
I have made mistake in board name(Z170-PLUS instead Z170M-PLUS), could you
please recheck with rebased patch?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #246 from Rob Miller (rob@janerob.com) ---
(In reply to Denis Pauk from comment #240)
> Created attachment 300963 [details]
> Asus WMI for nct6775 v5.17 base (2022.05.15)
> 
> (In reply to Rob Miller from comment #239)
> > Created attachment 300958 [details]
> > Asus Z170-DELUXE dump

> Unfortunately, your motherboard does not have any endpoints supported by
> upstreamed drivers. 
> 
> Could you please try with attached patch? It provides custom lock method
> that is unsupported by upstream driver.

Thank you for your continued efforts on this.

I installed the 5.18 base patch and was able to boot without the warning
messages.  

The nct6775 module loaded without issue, but 'sensors' command did not show all
the info for my device as it does booting the Ubuntu 5.15.0-33-generic kernel
with the 'acpi_enforce_resources=lax' option.  

nct675 reports: Found NCT6793D or compatible chip at 0x2e:0x290

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #247 from Sven Arvidsson (sa@whiz.se) ---
Created attachment 301046
  --> https://bugzilla.kernel.org/attachment.cgi?id=301046&action=edit
Z170M-PLUS crash

(In reply to Denis Pauk from comment #245)
> I have made mistake in board name(Z170-PLUS instead Z170M-PLUS), could you
> please recheck with rebased patch?
Thanks for the new patch! The chip is detected now, but unfortunately crashes
after loading. 

Crash log is attached.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #301030|0                           |1
        is obsolete|                            |

--- Comment #248 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 301047
  --> https://bugzilla.kernel.org/attachment.cgi?id=301047&action=edit
Asus WMI for nct6775 v5.18 base (2022.05.25)

(In reply to Sven Arvidsson from comment #247)
> Created attachment 301046 [details]
> Z170M-PLUS crash
> 
> (In reply to Denis Pauk from comment #245)
> > I have made mistake in board name(Z170-PLUS instead Z170M-PLUS), could you
> > please recheck with rebased patch?
> Thanks for the new patch! The chip is detected now, but unfortunately
> crashes after loading. 
> 
> Crash log is attached.
Welcome! I have added small fix for init, could you please try?

(In reply to Rob Miller from comment #246)
> (In reply to Denis Pauk from comment #240)
> > Created attachment 300963 [details]
> > Asus WMI for nct6775 v5.17 base (2022.05.15)
> > 
> > (In reply to Rob Miller from comment #239)
> > > Created attachment 300958 [details]
> > > Asus Z170-DELUXE dump
>  
> > Unfortunately, your motherboard does not have any endpoints supported by
> > upstreamed drivers. 
> > 
> > Could you please try with attached patch? It provides custom lock method
> > that is unsupported by upstream driver.
> 
> Thank you for your continued efforts on this.
> 
> I installed the 5.18 base patch and was able to boot without the warning
> messages.  
> 
> The nct6775 module loaded without issue, but 'sensors' command did not show
> all the info for my device as it does booting the Ubuntu 5.15.0-33-generic
> kernel with the 'acpi_enforce_resources=lax' option.  
> 
> nct675 reports: Found NCT6793D or compatible chip at 0x2e:0x290

Welcome! I have added little more debug information and additional check for
different name of mutex. could you please try?

Other possible issue can be different naming of vendor: "ASUSTeK COMPUTER INC."
vs "ASUSTeK Computer INC.".

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #249 from Sven Arvidsson (sa@whiz.se) ---
(In reply to Denis Pauk from comment #248)
> Welcome! I have added small fix for init, could you please try?

The third time's the charm! Everything is working fine now. 

All the sensor data previously visible with the acpi_enforce_resources=lax
option is there and PWM seems to be working fine.

Thanks for all the hard work you've done!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #250 from Rob Miller (rob@janerob.com) ---
(In reply to Denis Pauk from comment #248)

> (In reply to Rob Miller from comment #246)
> > > > Asus Z170-DELUXE dump

> Welcome! I have added little more debug information and additional check for
> different name of mutex. could you please try?
> 
> Other possible issue can be different naming of vendor: "ASUSTeK COMPUTER
> INC." vs "ASUSTeK Computer INC.".

1) Using second patch, again sensors doesn't work without the 'lax' boot
parameter, and there is a new error:

[    3.469698] nct6775: No such ASUS mutex: \_SB.PCI0.SBRG.SIO1.MUT0
[    3.470614] nct6775: Found NCT6793D or compatible chip at 0x2e:0x290
[    3.471418] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20211217/utaddress-204)
[    3.473062] ACPI: OSL: Resource conflict; ACPI support missing from driver?


2) Aplogies, I did find an error booting with the first patch:

[    3.501711] nct6775: Using Asus WMI mutex: \_SB_.PCI0.LPCB.SIO1.MUT0
[    3.501864] nct6775: Found NCT6793D or compatible chip at 0x2e:0x290
[    3.502050] BUG: kernel NULL pointer dereference, address: 0000000000000270
[    3.502060] #PF: supervisor write access in kernel mode
[    3.502068] #PF: error_code(0x0002) - not-present page
[    3.502076] PGD 0 P4D 0 
[    3.502087] Oops: 0002 [#1] PREEMPT SMP PTI
[    3.502102] CPU: 3 PID: 344 Comm: systemd-modules Not tainted 5.18.0 #2
[    3.502116] Hardware name: System manufacturer System Product
Name/Z170-DELUXE, BIOS 3801 03/14/2018
[    3.502121] RIP: 0010:nct6775_platform_probe+0x71/0x1b0 [nct6775]
[    3.502139] Code: 48 c7 c6 00 19 c8 8f 49 89 c7 e8 ca 26 0d ce 48 85 c0 0f
84 3b 01 00 00 49 8b 44 24 10 ba c0 0d 00 00 be 18 05 00 00 4c 89 f7 <48> 89 04
25 70 02 00 00 e8 72 9f 88 ce 48 89 c3 48 85 c0 0f 84 18
[    3.502144] RSP: 0018:ffffb5ab0093b828 EFLAGS: 00010286
[    3.502151] RAX: ffff8a17c1278720 RBX: ffffffffc03f6528 RCX:
0000000000000000
[    3.502156] RDX: 0000000000000dc0 RSI: 0000000000000518 RDI:
ffff8a17c4451810
[    3.502159] RBP: ffffb5ab0093b850 R08: ffff8a17c378bab8 R09:
0000000000000000
[    3.502162] R10: ffff8a17c378bf00 R11: 0000000000000000 R12:
ffff8a17c378b200
[    3.502166] R13: ffff8a17c4451800 R14: ffff8a17c4451810 R15:
ffff8a17c378ba80
[    3.502171] FS:  00007fe3c6f44900(0000) GS:ffff8a270ecc0000(0000)
knlGS:0000000000000000
[    3.502171] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.502175] CR2: 0000000000000270 CR3: 00000001109b2005 CR4:
00000000003706e0
[    3.502176] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[    3.502177] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[    3.502177] Call Trace:
[    3.502178]  <TASK>
[    3.508488] loop4: detected capacity change from 0 to 113736
[    3.510084]  platform_probe+0x49/0xc0
[    3.525183]  really_probe+0x1b5/0x390
[    3.525185]  __driver_probe_device+0x115/0x190
[    3.525186]  driver_probe_device+0x23/0xc0
[    3.525187]  __device_attach_driver+0xae/0x110
[    3.525188]  ? driver_allows_async_probing+0x60/0x60
[    3.525189]  bus_for_each_drv+0x85/0xd0
[    3.525192]  __device_attach+0xde/0x1f0
[    3.525193]  device_initial_probe+0x13/0x20
[    3.525194]  bus_probe_device+0x8f/0xa0
[    3.525195]  device_add+0x407/0x920
[    3.525196]  ? dev_set_name+0x53/0x70
[    3.525198]  ? preempt_count_add+0x7a/0xc0
[    3.525200]  platform_device_add+0x111/0x250
[    3.525201]  sensors_nct6775_platform_init+0x4c3/0x1000 [nct6775]
[    3.525204]  ? superio_wmi_exit+0x10/0x10 [nct6775]
[    3.525206]  ? superio_outb+0x20/0x20 [nct6775]
[    3.525207]  ? superio_inb+0x20/0x20 [nct6775]
[    3.525208]  ? superio_exit+0x40/0x40 [nct6775]
[    3.525210]  ? superio_wmi_outb+0x30/0x30 [nct6775]
[    3.525211]  ? 0xffffffffc037f000
[    3.525212]  do_one_initcall+0x49/0x210
[    3.525214]  ? kmem_cache_alloc_trace+0x1a6/0x300
[    3.538973]  do_init_module+0x52/0x250
[    3.538975]  load_module+0x27e5/0x2bd0
[    3.538978]  __do_sys_finit_module+0xc5/0x130
[    3.538980]  ? __do_sys_finit_module+0xc5/0x130
[    3.538982]  __x64_sys_finit_module+0x18/0x20
[    3.538983]  do_syscall_64+0x5c/0x80
[    3.538985]  ? exit_to_user_mode_prepare+0x49/0x190
[    3.538987]  ? syscall_exit_to_user_mode+0x26/0x40
[    3.538988]  ? __x64_sys_lseek+0x18/0x20
[    3.538990]  ? do_syscall_64+0x69/0x80
[    3.538992]  ? exit_to_user_mode_prepare+0x166/0x190
[    3.538993]  ? syscall_exit_to_user_mode+0x26/0x40
[    3.538994]  ? do_syscall_64+0x69/0x80
[    3.538995]  ? syscall_exit_to_user_mode+0x26/0x40
[    3.538996]  ? __x64_sys_finit_module+0x18/0x20
[    3.538998]  ? do_syscall_64+0x69/0x80
[    3.538999]  ? do_syscall_64+0x69/0x80
[    3.539001]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[    3.539002] RIP: 0033:0x7fe3c731ea3d
[    3.539004] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d c3 a3 0f 00 f7 d8 64 89 01 48
[    3.549209] RSP: 002b:00007ffd20e10708 EFLAGS: 00000246 ORIG_RAX:
0000000000000139
[    3.549210] RAX: ffffffffffffffda RBX: 0000562f4cf2ee70 RCX:
00007fe3c731ea3d
[    3.549211] RDX: 0000000000000000 RSI: 00007fe3c75f9441 RDI:
0000000000000007
[    3.549212] RBP: 0000000000020000 R08: 0000000000000000 R09:
0000000000000002
[    3.549212] R10: 0000000000000007 R11: 0000000000000246 R12:
00007fe3c75f9441
[    3.549213] R13: 0000562f4cf27160 R14: 00007fe3c781ccd0 R15:
0000562f4cf32360
[    3.549214]  </TASK>
[    3.549215] Modules linked in: nct6775(+) nct6775_core hwmon_vid lm92 jc42
coretemp ipmi_devintf ipmi_msghandler msr parport_pc ppdev lp parport drm
ip_tables x_tables autofs4 crc32_pclmul igb psmouse e1000e nvme i2c_i801
i2c_algo_bit i2
c_smbus nvme_core dca ahci libahci xhci_pci xhci_pci_renesas wmi video
[    3.549226] CR2: 0000000000000270
[    3.549227] ---[ end trace 0000000000000000 ]---
[    3.549227] RIP: 0010:nct6775_platform_probe+0x71/0x1b0 [nct6775]
[    3.549229] Code: 48 c7 c6 00 19 c8 8f 49 89 c7 e8 ca 26 0d ce 48 85 c0 0f
84 3b 01 00 00 49 8b 44 24 10 ba c0 0d 00 00 be 18 05 00 00 4c 89 f7 <48> 89 04
25 70 02 00 00 e8 72 9f 88 ce 48 89 c3 48 85 c0 0f 84 18
[    3.549230] RSP: 0018:ffffb5ab0093b828 EFLAGS: 00010286
[    3.549231] RAX: ffff8a17c1278720 RBX: ffffffffc03f6528 RCX:
0000000000000000
[    3.549232] RDX: 0000000000000dc0 RSI: 0000000000000518 RDI:
ffff8a17c4451810
[    3.549232] RBP: ffffb5ab0093b850 R08: ffff8a17c378bab8 R09:
0000000000000000
[    3.549233] R10: ffff8a17c378bf00 R11: 0000000000000000 R12:
ffff8a17c378b200
[    3.549233] R13: ffff8a17c4451800 R14: ffff8a17c4451810 R15:
ffff8a17c378ba80
[    3.549234] FS:  00007fe3c6f44900(0000) GS:ffff8a270ecc0000(0000)
knlGS:0000000000000000
[    3.549235] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.549235] CR2: 0000000000000270 CR3: 00000001109b2005 CR4:
00000000003706e0
[    3.549236] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[    3.549237] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[    3.568106] systemd[1]: Mounting Mount unit for core20, revision 1434...

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #301047|0                           |1
        is obsolete|                            |

--- Comment #251 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 301099
  --> https://bugzilla.kernel.org/attachment.cgi?id=301099&action=edit
Asus WMI for nct6775 v5.18 base (2022.06.03)

(In reply to Rob Miller from comment #250)
> (In reply to Denis Pauk from comment #248)
> 
> > (In reply to Rob Miller from comment #246)
> > > > > Asus Z170-DELUXE dump
>  
> > Welcome! I have added little more debug information and additional check
> for
> > different name of mutex. could you please try?
> > 
> > Other possible issue can be different naming of vendor: "ASUSTeK COMPUTER
> > INC." vs "ASUSTeK Computer INC.".
> 
> 1) Using second patch, again sensors doesn't work without the 'lax' boot
> parameter, and there is a new error:
> 
> [    3.469698] nct6775: No such ASUS mutex: \_SB.PCI0.SBRG.SIO1.MUT0
> 
> 2) Aplogies, I did find an error booting with the first patch:
> 
> [    3.501711] nct6775: Using Asus WMI mutex: \_SB_.PCI0.LPCB.SIO1.MUT0
> [    3.501864] nct6775: Found NCT6793D or compatible chip at 0x2e:0x290

Could you please check?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #252 from Rob Miller (rob@janerob.com) ---
(In reply to Denis Pauk from comment #251)
> Created attachment 301099 [details]
> Asus WMI for nct6775 v5.18 base (2022.06.03)
> 
> (In reply to Rob Miller from comment #250)

> Could you please check?

Score!

sensors command fully working, no issues in dmesg, no 'lax' boot parameter.

Thank you! and well done!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Michael Carns (mike@carns.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@carns.com

--- Comment #253 from Michael Carns (mike@carns.com) ---
Created attachment 301145
  --> https://bugzilla.kernel.org/attachment.cgi?id=301145&action=edit
Add Maximus XI Hero

I have an older Maximus XI Hero (WiFi) that works fine once I add it to the
appropriate lists.  I'm attaching the patch I've been using on top of the
existing nct6775.patch.  Hopefully, it can get integrated into the next
iteration.

Thanks!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #254 from Eugene Shalygin (eugene.shalygin@gmail.com) ---
(In reply to Michael Carns from comment #253)
> Created attachment 301145 [details]
> Add Maximus XI Hero
> 
> I have an older Maximus XI Hero (WiFi) that works fine once I add it to the
> appropriate lists.  I'm attaching the patch I've been using on top of the
> existing nct6775.patch.  Hopefully, it can get integrated into the next
> iteration.
> 
> Thanks!

Thank you for the EC patch! To mainline it we need to check the HW mutex name,
and there is a mistake in the attached patch: MAX_IDENTICAL_BOARD_VARIATIONS
needs to be increased for it to work. Or, if it works as is, there is a mistake
in the asus-ec-sensors driver code. 

Thus, could you, please, register a pull request or an issue at
https://github.com/zeule/asus-ec-sensors to resolve that and mainline the
change?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #255 from renedis (renedis@hotmail.com) ---
Thanks all! With kernel 5.17 it didn't worked without manually patching. I've
skipped kernel 5.18 but can confirm that kernel 5.19 works OOTB:

nct6798-isa-0290
Adapter: ISA adapter
in0:                      664.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                        1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.28 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.36 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                      992.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      832.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      240.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.28 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.22 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      496.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     608.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     592.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                     1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     232.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     376.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                     2235 RPM  (min =    0 RPM)
fan2:                     2224 RPM  (min =    0 RPM)
fan3:                        0 RPM  (min =    0 RPM)
fan4:                        0 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +35.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +33.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +91.0°C    sensor = thermistor
AUXTIN1:                   +15.0°C    sensor = thermistor
AUXTIN2:                   +16.0°C    sensor = thermistor
AUXTIN3:                   +75.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +32.0°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
intrusion0:               OK
intrusion1:               ALARM
beep_enable:              disabled

Kernel:
5.19.0-051900-generic


Many thanks again!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #256 from Vladdrako (vladdrako007@gmail.com) ---
@Eugene Shalygin
Can you create patch for the 5.19 kernel, please?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #301099|0                           |1
        is obsolete|                            |

--- Comment #257 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 302999
  --> https://bugzilla.kernel.org/attachment.cgi?id=302999&action=edit
Asus WMI for nct6775 v5.19 base (2022.10.14)

Hwmon changes v5.19..v5.20 + nct6775 locks

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #258 from Vladdrako (vladdrako007@gmail.com) ---
@Denis Pauk
Something wrong with the patch, it has only commit headers :)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #302999|0                           |1
        is obsolete|                            |

--- Comment #259 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303000
  --> https://bugzilla.kernel.org/attachment.cgi?id=303000&action=edit
Asus WMI for nct6775 v5.19 base (2022.10.14)

(In reply to Vladdrako from comment #258)
> @Denis Pauk
> Something wrong with the patch, it has only commit headers :)

Could you please check now?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #260 from Vladdrako (vladdrako007@gmail.com) ---
(In reply to Denis Pauk from comment #259)
> Created attachment 303000 [details]
> Asus WMI for nct6775 v5.19 base (2022.10.14)
> 
> (In reply to Vladdrako from comment #258)
> > @Denis Pauk
> > Something wrong with the patch, it has only commit headers :)
> 
> Could you please check now?

It works ok, thanks.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Jure Repinc (jlp.bugs@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jlp.bugs@gmail.com

--- Comment #261 from Jure Repinc (jlp.bugs@gmail.com) ---
Created attachment 303020
  --> https://bugzilla.kernel.org/attachment.cgi?id=303020&action=edit
Asus P8H67 DSDT

Is Asus P8H67 also a MB that could have support added?

DSDT attached.

dmidecode:
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: P8H67
        Version: Rev X.0x
        Serial Number: MF70B3G04701427
        Asset Tag: To be filled by O.E.M.
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis: To be filled by O.E.M.
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0

dmesg:
[207642.852150] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
[207642.852158] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\_GPE.HWRE) (20220331/utaddress-204)
[207642.852163] ACPI: OSL: Resource conflict; ACPI support missing from driver?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303000|0                           |1
        is obsolete|                            |

--- Comment #262 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303031
  --> https://bugzilla.kernel.org/attachment.cgi?id=303031&action=edit
Asus WMI for nct6775 v5.20 base (2022.10.18)

(In reply to Jure Repinc from comment #261)
> Created attachment 303020 [details]
> Asus P8H67 DSDT
> 
> Is Asus P8H67 also a MB that could have support added?

P8H67 does not have support of WMI interfaces that currently used for ASUS
boards in kernel. Also it looks like access to nct6775 is not guarded by any
mutex locks in code section with sensors registers region. (It can be really
dangerous to use 
 registers directly)

I have added use lock from different section that also used in other bioses as
lock. Could you please check?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303031|0                           |1
        is obsolete|                            |

--- Comment #263 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303045
  --> https://bugzilla.kernel.org/attachment.cgi?id=303045&action=edit
Asus WMI for nct6775 v5.20 base (2022.10.20)

Updated patch with X670 board support, based on patch from Ahmad Khalifa,

https://patchwork.kernel.org/project/linux-hwmon/patch/20221018173428.71080-1-ahmad@khalifa.ws/

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

zykr.caswell@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zykr.caswell@gmail.com

--- Comment #264 from zykr.caswell@gmail.com ---
Created attachment 303116
  --> https://bugzilla.kernel.org/attachment.cgi?id=303116&action=edit
DSDT - X99-E-WS-USB3 - Decompiled

Same or similar issue with X99-E WS/USB 3.1:

nct6775: Found NCT6791D or compatible chip at 0x2e:0x290
ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts
with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM)
(20200925/utaddress-204)

I've been trying to make sense of the DSDT by reading the ACPI spec, but I'm
not having a lot success. Built kernels 5.10, 5.19, 6.0.2, 6.03, and several
different versions of nct6775 driver for each including "Asus WMI for nct6775
v5.20 base (2022.10.20)", both in tree and as a custom DKMS module to no
effect.

I'm rather reluctant to actually try using acpi_enforce_resourses=lax, so I
don't know for sure if that would make it work or not. I've attached my DSDT as
pulled from the latest BIOS update for my board from ASUS. Could someone take a
look and confirm for me that I likely have this same problem?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #265 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to zykr.caswell from comment #264)
> Created attachment 303116 [details]
> DSDT - X99-E-WS-USB3 - Decompiled
> 
> Same or similar issue with X99-E WS/USB 3.1:
> 
> nct6775: Found NCT6791D or compatible chip at 0x2e:0x290
> ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts
> with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM)
> (20200925/utaddress-204)
> 
> I've been trying to make sense of the DSDT by reading the ACPI spec, but I'm
> not having a lot success. Built kernels 5.10, 5.19, 6.0.2, 6.03, and several
> different versions of nct6775 driver for each including "Asus WMI for
> nct6775 v5.20 base (2022.10.20)", both in tree and as a custom DKMS module
> to no effect.
> 
> I'm rather reluctant to actually try using acpi_enforce_resourses=lax, so I
> don't know for sure if that would make it work or not. I've attached my DSDT
> as pulled from the latest BIOS update for my board from ASUS. Could someone
> take a look and confirm for me that I likely have this same problem?

Could you please apply patch and add line with you board and recheck? Change
should be like "DMI_MATCH_ASUS_WMI_BOARD("<You board name>",
&acpi_board_LPCB_MUTEX)," near "MAXIMUS VII HERO" definition.

Name board should be from /sys/class/dmi/id/board_name.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #266 from zykr.caswell@gmail.com ---
TLDR: B-->0 and it works!

Adding the board to that list, which I'm feeling a little embarrassed I hadn't
already tried, gives this: 
nct6775_dkms_platform: No such ASUS mutex: \_SB_.PCI0.LPCB.SIO1.MUT0
nct6775_dkms_platform: Found NCT6791D or compatible chip at 0x2e:0x290
ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts
with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM)
(20220331/utaddress-204)
ACPI: OSL: Resource conflict; ACPI support missing from driver?

Looking at the DKMS, I don't have such a Mutex, but I do have one under LPC0
instead of LPCB.
Scope (_SB) --> Device (PCI0) --> Device (LPC0) --> Device (SIO1) --> Mutex
(MUT0, 0x00)

Adding that in results in... IT WORKS! I had almost given up by this point and
was main continuing out of stubbornness rather than any actual expectation of
getting it working.

So, thank you, thank you very much. I'm not sure all of the values are right as
the temperatures seem rather high, but I will try to confirm that now.



ADDED:
+    DMI_ASUS_BOARD_INFO(acpi_board_LPC0_MUTEX, "\\_SB_.PCI0.LPC0.SIO1.MUT0");
...
DMI_MATCH_ASUS_NONWMI_BOARD("P8Z68-V LX", &acpi_board_LPCB_MUTEX),
+    /* SB_.PCI0.LPC0.SIO1.MUT0*/
+    DMI_MATCH_ASUS_WMI_BOARD("X99-E WS/USB 3.1", &acpi_board_LPC0_MUTEX),
+    /* SB_.PCI0.LPCB.SIO1.MUT0*/
DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS VII HERO", &acpi_board_LPCB_MUTEX),

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303045|0                           |1
        is obsolete|                            |

--- Comment #267 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303126
  --> https://bugzilla.kernel.org/attachment.cgi?id=303126&action=edit
Asus WMI for nct6775 v5.20 base (2022.11.03)

(In reply to zykr.caswell from comment #266)
> TLDR: B-->0 and it works!

Thank you, I have updated patch with your board.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

yutesdb (mundanedefoliation@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mundanedefoliation@gmail.co
                   |                            |m

--- Comment #268 from yutesdb (mundanedefoliation@gmail.com) ---
can add support TUF GAMING B550M-PLUS WIFI II?

I tried add parameter acpi_enforce_resources=lax, it works.

# dmidecode 3.4
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: TUF GAMING B550M-PLUS WIFI II
        Version: Rev X.0x
        Serial Number: 220909970904631
        Asset Tag: Default string
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis: Default string
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0


cat /sys/class/dmi/id/board_name
TUF GAMING B550M-PLUS WIFI II

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303126|0                           |1
        is obsolete|                            |

--- Comment #269 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303161
  --> https://bugzilla.kernel.org/attachment.cgi?id=303161&action=edit
Asus WMI for nct6775 v6.0 base (2022.11.12)

(In reply to yutesdb from comment #268)
> can add support TUF GAMING B550M-PLUS WIFI II?
> 
> I tried add parameter acpi_enforce_resources=lax, it works.

Could you please now?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #270 from yutesdb (mundanedefoliation@gmail.com) ---
(In reply to Denis Pauk from comment #269)
> Created attachment 303161 [details]
> Asus WMI for nct6775 v6.0 base (2022.11.12)
> 
> (In reply to yutesdb from comment #268)
> > can add support TUF GAMING B550M-PLUS WIFI II?
> > 
> > I tried add parameter acpi_enforce_resources=lax, it works.
> 
> Could you please now?

thanks, it works, only compile hwmon modules, without
acpi_enforce_resources=lax parameter.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Slawomir Stepien (sst@poczta.fm) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sst@poczta.fm

--- Comment #271 from Slawomir Stepien (sst@poczta.fm) ---
Created attachment 303265
  --> https://bugzilla.kernel.org/attachment.cgi?id=303265&action=edit
Add support for ROG STRIX B660-I GAMING WIFI

This adds support for ROG STRIX B660-I GAMING WIFI into the "Asus WMI for
nct6775 v6.0 base (2022.11.12)" patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #272 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Slawomir Stepien from comment #271)
> Created attachment 303265 [details]
> Add support for ROG STRIX B660-I GAMING WIFI
> 
> This adds support for ROG STRIX B660-I GAMING WIFI into the "Asus WMI for
> nct6775 v6.0 base (2022.11.12)" patch.

Thank you! I will add your code to the next patch version.

Just for recheck, could you please share error place on init when you added
your board to asus_acpi_boards(x670 generation methods) or
asus_wmi_boards(b550/x570 generation methods)? Are both of methods of access
failed? 

I have hoped B660 boards have same access method as x670 boards at least :-(

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #273 from Slawomir Stepien (sst@poczta.fm) ---
(In reply to Denis Pauk from comment #272)
> (In reply to Slawomir Stepien from comment #271)
> > Created attachment 303265 [details]
> > Add support for ROG STRIX B660-I GAMING WIFI
> > 
> > This adds support for ROG STRIX B660-I GAMING WIFI into the "Asus WMI for
> > nct6775 v6.0 base (2022.11.12)" patch.
> 
> Thank you! I will add your code to the next patch version.
> 
> Just for recheck, could you please share error place on init when you added
> your board to asus_acpi_boards(x670 generation methods) or
> asus_wmi_boards(b550/x570 generation methods)? Are both of methods of access
> failed? 
> 
> I have hoped B660 boards have same access method as x670 boards at least :-(

[93233.798384] nct6775: Can't read ChipID by Asus WMI.
[93233.798386] nct6775: No dmi definition `ROG STRIX B660-I GAMING
WIFI`:`ASUSTeK COMPUTER INC.`
[93233.798446] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[93233.798449] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\RMTW.SHWM) (20220331/utaddress-204)
[93233.798452] ACPI: OSL: Resource conflict; ACPI support missing from driver?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #274 from Slawomir Stepien (sst@poczta.fm) ---
(In reply to Slawomir Stepien from comment #273)
> (In reply to Denis Pauk from comment #272)
> > (In reply to Slawomir Stepien from comment #271)
> > > Created attachment 303265 [details]
> > > Add support for ROG STRIX B660-I GAMING WIFI
> > > 
> > > This adds support for ROG STRIX B660-I GAMING WIFI into the "Asus WMI for
> > > nct6775 v6.0 base (2022.11.12)" patch.
> > 
> > Thank you! I will add your code to the next patch version.
> > 
> > Just for recheck, could you please share error place on init when you added
> > your board to asus_acpi_boards(x670 generation methods) or
> > asus_wmi_boards(b550/x570 generation methods)? Are both of methods of
> access
> > failed? 
> > 
> > I have hoped B660 boards have same access method as x670 boards at least
> :-(
> 
> [93233.798384] nct6775: Can't read ChipID by Asus WMI.
> [93233.798386] nct6775: No dmi definition `ROG STRIX B660-I GAMING
> WIFI`:`ASUSTeK COMPUTER INC.`
> [93233.798446] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
> [93233.798449] ACPI Warning: SystemIO range
> 0x0000000000000295-0x0000000000000296 conflicts with OpRegion
> 0x0000000000000290-0x0000000000000299 (\RMTW.SHWM) (20220331/utaddress-204)
> [93233.798452] ACPI: OSL: Resource conflict; ACPI support missing from
> driver?

But if I add the board to the asus_acpi_boards, it works but with:

[93515.558164] nct6775: Using Asus ACPI to access 0xc1 chip.
[93515.558166] nct6775: No dmi definition `ROG STRIX B660-I GAMING
WIFI`:`ASUSTeK COMPUTER INC.`
[93515.558229] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290

So I guess this is a better approach for my case?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #275 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Slawomir Stepien from comment #274)
> (In reply to Slawomir Stepien from comment #273)
> > (In reply to Denis Pauk from comment #272)
> > > (In reply to Slawomir Stepien from comment #271)
> > > > Created attachment 303265 [details]
> > > > Add support for ROG STRIX B660-I GAMING WIFI
> > > > 
> > > > This adds support for ROG STRIX B660-I GAMING WIFI into the "Asus WMI
> for
> > > > nct6775 v6.0 base (2022.11.12)" patch.
> > > 
> > > Thank you! I will add your code to the next patch version.
> > > 
> > > Just for recheck, could you please share error place on init when you
> added
> > > your board to asus_acpi_boards(x670 generation methods) or
> > > asus_wmi_boards(b550/x570 generation methods)? Are both of methods of
> > access
> > > failed? 
> > > 
> > > I have hoped B660 boards have same access method as x670 boards at least
> > :-(
> > 
> > [93233.798384] nct6775: Can't read ChipID by Asus WMI.
> > [93233.798386] nct6775: No dmi definition `ROG STRIX B660-I GAMING
> > WIFI`:`ASUSTeK COMPUTER INC.`
> > [93233.798446] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
> > [93233.798449] ACPI Warning: SystemIO range
> > 0x0000000000000295-0x0000000000000296 conflicts with OpRegion
> > 0x0000000000000290-0x0000000000000299 (\RMTW.SHWM) (20220331/utaddress-204)
> > [93233.798452] ACPI: OSL: Resource conflict; ACPI support missing from
> > driver?
> 
> But if I add the board to the asus_acpi_boards, it works but with:
> 
> [93515.558164] nct6775: Using Asus ACPI to access 0xc1 chip.
> [93515.558166] nct6775: No dmi definition `ROG STRIX B660-I GAMING
> WIFI`:`ASUSTeK COMPUTER INC.`
> [93515.558229] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
> 
> So I guess this is a better approach for my case?

It should be, its near to correct way as its designed by ASUS. Its not clear
for now how to make such calls by WMI, i suppose that they have changed WMI
method ID to some different or hide it behind other methods.  

Look to the X670 patch discussion:
https://patchwork.kernel.org/project/linux-hwmon/patch/20221018173428.71080-1-ahmad@khalifa.ws/

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303161|0                           |1
        is obsolete|                            |

--- Comment #276 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303333
  --> https://bugzilla.kernel.org/attachment.cgi?id=303333&action=edit
Asus WMI for nct6775 v6.0 base (2022.12.01)

Added:
* PRIME B450-PLUS 
* ROG STRIX B660-I GAMING WIFI

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Rob Crittenden (rcrit@greyoak.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rcrit@greyoak.com

--- Comment #277 from Rob Crittenden (rcrit@greyoak.com) ---
The MB "ROG CROSSHAIR VIII HERO" is already in the supported list. There is a
wi-fi edition as well. Can it be added to the allow list?

$ cat /sys/class/dmi/id/board_name
ROG CROSSHAIR VIII HERO (WI-FI)

I built the nct6775* code with this name included as a module using dkms and
tested it for a few weeks with kernels 6.0.1[0-2] on Fedora 37 successfully.

[30073.435475] nct6775: Using Asus WMI to access 0xc1 chip.
[30073.435509] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303333|0                           |1
        is obsolete|                            |

--- Comment #278 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303466
  --> https://bugzilla.kernel.org/attachment.cgi?id=303466&action=edit
Asus WMI for nct6775 v6.1 base (2022.12.24)

Simplified version of patch with removed custom i2c adapter and reworked access
to sensors on previous generation of boards (<=AMD B550/X570) and additional
new generation boards(AMD B650/X670).

B550/X570 style:
        "CROSSHAIR VI HERO", // use custom port definition
        "PRIME B360-PLUS",
        "PRIME B450-PLUS", // use custom port definition
        "PRIME B450M-GAMING II", // use custom port definition
        "PRIME B450M-GAMING/BR", // use custom port definition
        "PRIME B460-PLUS",
        "PRIME B550-PLUS",
        "PRIME B550M-A",
        "PRIME B550M-A (WI-FI)",
        "PRIME B550M-A AC",
        "PRIME B550M-A WIFI II",
        "PRIME B550M-K",
        "PRIME H410M-R",
        "PRIME X370-PRO", // use custom port definition
        "PRIME X470-PRO", // use custom port definition
        "PRIME X570-P",
        "PRIME X570-PRO",
        "PRO H410T",
        "Pro B550M-C",
        "Pro WS X570-ACE",
        "ProArt B550-CREATOR",
        "ProArt X570-CREATOR WIFI",
        "ProArt Z490-CREATOR 10G",
        "ROG CROSSHAIR VI EXTREME", // use custom port definition
        "ROG CROSSHAIR VI HERO (WI-FI AC)", // use custom port definition
        "ROG CROSSHAIR VII HERO", // use custom port definition
        "ROG CROSSHAIR VII HERO (WI-FI)", // use custom port definition
        "ROG CROSSHAIR VIII DARK HERO",
        "ROG CROSSHAIR VIII EXTREME",
        "ROG CROSSHAIR VIII FORMULA",
        "ROG CROSSHAIR VIII HERO",
        "ROG CROSSHAIR VIII HERO (WI-FI)",
        "ROG CROSSHAIR VIII IMPACT",
        "ROG MAXIMUS XI HERO",
        "ROG MAXIMUS XI HERO (WI-FI)",
        "ROG STRIX B350-F GAMING", // use custom port definition
        "ROG STRIX B350-I GAMING", // use custom port definition
        "ROG STRIX B450-E GAMING", // use custom port definition
        "ROG STRIX B450-F GAMING", // use custom port definition
        "ROG STRIX B450-F GAMING II", // use custom port definition
        "ROG STRIX B450-I GAMING", // use custom port definition
        "ROG STRIX B550-A GAMING",
        "ROG STRIX B550-E GAMING",
        "ROG STRIX B550-F GAMING",
        "ROG STRIX B550-F GAMING (WI-FI)",
        "ROG STRIX B550-F GAMING WIFI II",
        "ROG STRIX B550-I GAMING",
        "ROG STRIX B550-XE GAMING (WI-FI)",
        "ROG STRIX X370-F GAMING", // use custom port definition
        "ROG STRIX X370-I GAMING", // use custom port definition
        "ROG STRIX X470-F GAMING", // use custom port definition
        "ROG STRIX X470-I GAMING", // use custom port definition
        "ROG STRIX X570-E GAMING",
        "ROG STRIX X570-E GAMING WIFI II",
        "ROG STRIX X570-F GAMING",
        "ROG STRIX X570-I GAMING",
        "ROG STRIX Z390-E GAMING",
        "ROG STRIX Z390-F GAMING",
        "ROG STRIX Z390-H GAMING",
        "ROG STRIX Z390-I GAMING",
        "ROG STRIX Z490-A GAMING",
        "ROG STRIX Z490-E GAMING",
        "ROG STRIX Z490-F GAMING",
        "ROG STRIX Z490-G GAMING",
        "ROG STRIX Z490-G GAMING (WI-FI)",
        "ROG STRIX Z490-H GAMING",
        "ROG STRIX Z490-I GAMING",
        "TUF B450 PLUS GAMING", // use custom port definition
        "TUF GAMING B450-PLUS II", // use custom port definition
        "TUF GAMING B550-PLUS",
        "TUF GAMING B550-PLUS WIFI II",
        "TUF GAMING B550-PRO",
        "TUF GAMING B550M-E",
        "TUF GAMING B550M-E (WI-FI)",
        "TUF GAMING B550M-PLUS",
        "TUF GAMING B550M-PLUS (WI-FI)",
        "TUF GAMING B550M-PLUS WIFI II",
        "TUF GAMING X570-PLUS",
        "TUF GAMING X570-PLUS (WI-FI)",
        "TUF GAMING X570-PRO (WI-FI)",
        "TUF GAMING Z490-PLUS",
        "TUF GAMING Z490-PLUS (WI-FI)",
        "Z490-GUNDAM (WI-FI)",

B650/X670:
        "PRIME B650-PLUS",
        "PRIME B650M-A",
        "PRIME B650M-A (WI-FI)",
        "ProArt B660-CREATOR D4",
        "ProArt X670E-CREATOR WIFI",
        "ProArt Z790-CREATOR WIFI", // use custom port definition
        "ROG CROSSHAIR X670E EXTREME",
        "ROG CROSSHAIR X670E GENE",
        "ROG CROSSHAIR X670E HERO",
        "ROG MAXIMUS XIII EXTREME GLACIAL",
        "ROG MAXIMUS Z690 EXTREME",
        "ROG MAXIMUS Z690 EXTREME GLACIAL",
        "ROG MAXIMUS Z790 EXTREME", // use custom port definition
        "ROG STRIX B650E-E GAMING (WI-FI)",
        "ROG STRIX B650E-F GAMING (WI-FI)",
        "ROG STRIX B660-I GAMING WIFI",
        "ROG STRIX X670E-A GAMING WIFI",
        "ROG STRIX X670E-E GAMING WIFI",
        "ROG STRIX X670E-F GAMING WIFI",
        "ROG STRIX X670E-I GAMING WIFI",
        "ROG STRIX Z590-A GAMING WIFI II",
        "ROG STRIX Z690-A GAMING WIFI D4",
        "TUF GAMING Z590-PLUS WIFI",

By mutex lock:
        DMI_MATCH_ASUS_NONWMI_BOARD("P8Z68-V LX", &acpi_board_LPCB_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("CROSSHAIR VI HERO", &acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS IX APEX", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS IX CODE", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS IX EXTREME", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS IX FORMULA", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS IX HERO", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS VII HERO", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("P8H67", &acpi_board_LPCB_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("PRIME B450M-GAMING/BR",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("PRIME B450M-GAMING II",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("PRIME B450-PLUS", &acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("PRIME X370-PRO", &acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("PRIME X470-PRO", &acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("PRIME Z270-A", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ProArt Z790-CREATOR WIFI",
&acpi_board_0LPC_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG CROSSHAIR VI EXTREME",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG CROSSHAIR VI HERO (WI-FI AC)",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG CROSSHAIR VII HERO",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG CROSSHAIR VII HERO (WI-FI)",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG MAXIMUS X HERO", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG MAXIMUS Z790 EXTREME",
&acpi_board_0LPC_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B350-F GAMING",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B350-I GAMING",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B450-E GAMING",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B450-F GAMING",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B450-F GAMING II",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B450-I GAMING",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX X370-F GAMING",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX X370-I GAMING",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX X470-F GAMING",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX X470-I GAMING",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX Z370-H GAMING",
&acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("STRIX-Z270E-GAMING", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("STRIX-Z270F-GAMING", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("STRIX-Z270G-GAMING", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("STRIX-Z270H-GAMING", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("TUF B450 PLUS GAMING",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("TUF GAMING B450-PLUS II",
&acpi_board_SBRG_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("TUF Z270 MARK 1", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("Z170-DELUXE", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("Z170M-PLUS", &acpi_board_GPEM_MUTEX),
        DMI_MATCH_ASUS_WMI_BOARD("Z270-WS", &acpi_board_GPEM_MUTEX),

If boards are in several lists, access could be possible by several methods.

If new patch will work for you, I will start to prepare patches for upstream
review(except mutex changes).

Boards with "use custom port definition" mark could be in such patches only
after test with real board as such boards use little different method
definitions than in fully tested boards.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #279 from Thomas Langkamp (thomas.langkamp@medicalschool-hamburg.de) ---
Sehr geehrte Damen und Herren, vielen Dank für Ihre Nachricht. Ich bin am 9.1.
wieder im Büro. Mit freundlichen Grüßen Thomas Langkamp, Dozent für Statistik
und Wissenschaftliche Arbeit MSH Medical School Hamburg

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Jeroen Beerstra (jeroen@beerstra.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeroen@beerstra.org

--- Comment #280 from Jeroen Beerstra (jeroen@beerstra.org) ---
(In reply to Denis Pauk from comment #278)

I was succesfull in enabling the monitoring for my Asus X670-P motherboard on
kernel 6.1.2 running on Almalinux. First of all I added my board to DMI section
of you r patch and second I added it to asus_wmi_sensors. The patch didn't
apply fully though on ML linux but manually editing nct6775-platform was
trivial for me (I just needed to add Asus X670-P to the list and didn't bother
to sort out the differences in the list from the patch and linux 6.1.2). I
still need to modprobe nct6775 and lmsensors doesn't detect my sensors OOTB.
But the module loads cleanly and I see sensors readings :)

nct6799-isa-0290
Adapter: ISA adapter
in0:                        1.21 V  (min =  +0.00 V, max =  +1.74 V)
in1:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                        1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                        1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      784.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.30 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                        1.67 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     560.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     552.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     496.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     424.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                      681 RPM  (min =    0 RPM)
fan2:                      512 RPM  (min =    0 RPM)
fan3:                      639 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +30.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +34.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +38.0°C    sensor = thermistor
AUXTIN1:                   +19.0°C    sensor = thermistor
AUXTIN2:                   +20.0°C    sensor = thermistor
AUXTIN3:                   +73.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +35.5°C
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C
PCH_CHIP_TEMP:              +0.0°C
PCH_CPU_TEMP:               +0.0°C
TSI0_TEMP:                 +46.4°C
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

Not all is correct (for example one of the 2 case fans is missing from the
list) but at least I'm getting somewhere, thanx! :)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303466|0                           |1
        is obsolete|                            |

--- Comment #281 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303548
  --> https://bugzilla.kernel.org/attachment.cgi?id=303548&action=edit
Asus WMI for nct6775 v6.1 base (2023.01.07)

(In reply to Jeroen Beerstra from comment #280)
(In reply to Slawomir Stepien from comment #274)

Could you check with new patch? It contains updated Fan and Temperature sensors
support.

https://patchwork.kernel.org/project/linux-hwmon/patch/20221228135744.281752-1-linux@roeck-us.net/
https://patchwork.kernel.org/project/linux-hwmon/patch/20230102212857.5670-1-zev@bewilderbeest.net/

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #282 from Jeroen Beerstra (jeroen@beerstra.org) ---
Looks good to me:

$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +64.0°C  
Tccd1:        +35.4°C  
Tccd2:        +35.1°C  

nct6799-isa-0290
Adapter: ISA adapter
in0:                        1.37 V  (min =  +0.00 V, max =  +1.74 V)
in1:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                        1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                        1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      752.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.30 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                        1.67 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     560.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     560.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     496.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     424.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                      755 RPM  (min =    0 RPM)
fan2:                      819 RPM  (min =    0 RPM)
fan3:                      712 RPM  (min =    0 RPM)
fan4:                        0 RPM  (min =    0 RPM)
fan5:                      674 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +31.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +36.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +39.5°C    sensor = thermistor
AUXTIN1:                   +19.0°C    sensor = thermistor
AUXTIN2:                   +20.0°C    sensor = thermistor
AUXTIN3:                   +73.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +54.0°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
TSI0_TEMP:                 +64.5°C  
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

amdgpu-pci-0e00
Adapter: PCI adapter
vddgfx:        1.34 V  
vddnb:         1.01 V  
edge:         +41.0°C  
PPT:          55.25 W  

Linux beerstra 6.1.4-1.el9_1.beerstra.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jan  7
19:36:39 CET 2023 x86_64 x86_64 x86_64 GNU/Linux

The patch didn't apply cleanly to 6.1.4 though, but that is because some boards
were already included. Voltages seem off though.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303548|0                           |1
        is obsolete|                            |

--- Comment #283 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303610
  --> https://bugzilla.kernel.org/attachment.cgi?id=303610&action=edit
Asus WMI for nct6775 v6.1 base (2023.01.15)

Rebased patch to new commits from hwmon-next

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

nikodll@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nikodll@gmail.com

--- Comment #284 from nikodll@gmail.com ---
I have the same or related issue with Asus Pro WS W680-ACE IPMI motherboard.
The following dmesg output is produced when I'm trying to "modprobe nct6775"
and lm_sensors do not show any PWM fan/temp values from this chip:

[ 1001.509854] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[ 1001.509868] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\RMTW.SHWM) (20220331/utaddress-204)
[ 1001.509880] ACPI: OSL: Resource conflict; ACPI support missing from driver?

$ cat /sys/class/dmi/id/board_name
Pro WS W680-ACE IPMI

$ zcat /proc/config.gz | grep -i asus
CONFIG_USB_PEGASUS=m
CONFIG_TABLET_USB_PEGASUS=m
CONFIG_SENSORS_ASUS_WMI=m
CONFIG_SENSORS_ASUS_EC=m
CONFIG_HID_ASUS=m
CONFIG_ASUS_LAPTOP=m
CONFIG_ASUS_WIRELESS=m
CONFIG_ASUS_WMI=m
CONFIG_ASUS_NB_WMI=m
CONFIG_ASUS_TF103C_DOCK=m

$ lsmod | grep -i -E \(wmi\|asus\)
wmi                    32768  1 video

$ uname -a
Linux calculate 6.1.7-gentoo-dist #1 SMP PREEMPT_DYNAMIC Wed Jan 18 12:31:42
-00 2023 x86_64 13th Gen Intel(R) Core(TM) i9-13900 GenuineIntel GNU/Linux

Is there any way how I can assist in resolving it, testing patches etc?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303610|0                           |1
        is obsolete|                            |

--- Comment #285 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303655
  --> https://bugzilla.kernel.org/attachment.cgi?id=303655&action=edit
Asus WMI for nct6775 v6.1 base (2023.01.26)

(In reply to Nikita Koval from comment #284)
> I have the same or related issue with Asus Pro WS W680-ACE IPMI motherboard.
> The following dmesg output is produced when I'm trying to "modprobe nct6775"
> and lm_sensors do not show any PWM fan/temp values from this chip:

Could you try with such path? Difference with previous patch is your board
added to asus_msi_boards. ASUS EC controller endpoint looks not implemented for
you board and only nct6775 is required for show sensors data.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #286 from Nikita Koval (nikodll@gmail.com) ---
(In reply to Denis Pauk from comment #285)
> Created attachment 303655 [details]
> Asus WMI for nct6775 v6.1 base (2023.01.26)
> 

Thanks for the patch! It didn't work right away with my current 6.1.7-gentoo
kernel though, but I was able to apply it against vanilla v6.0. The sensors
from 6798D chip seem working now (at least the ones that I care about, like fan
values):


nct6798-isa-0290
Adapter: ISA adapter
in0:                      144.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                        1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.41 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.33 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                        0.00 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                        0.00 V  (min =  +0.00 V, max =  +0.00 V)
in7:                        3.41 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.23 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      528.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     504.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                       0.00 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.06 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     392.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     896.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                        0 RPM  (min =    0 RPM)
fan2:                     1124 RPM  (min =    0 RPM)
fan3:                        0 RPM  (min =    0 RPM)
fan4:                        0 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +28.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +38.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                  -128.0°C    sensor = thermistor
AUXTIN1:                   +25.0°C    sensor = thermistor
AUXTIN2:                  +127.0°C    sensor = thermistor
AUXTIN3:                   +32.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +38.5°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:             +55.0°C  
PCH_CPU_TEMP:               +0.0°C  
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

I will be using this kernel for a while and will report if I notice any related
issues.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Robert Kling (robert.kling@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robert.kling@gmail.com

--- Comment #287 from Robert Kling (robert.kling@gmail.com) ---
Created attachment 303659
  --> https://bugzilla.kernel.org/attachment.cgi?id=303659&action=edit
dsdt.dat Z170 PRO GAMING/AURA

Hello, would it be possible to add support for Asus Z170 PRO GAMING/AURA?

cat /sys/class/dmi/id/board_name:
Z170 PRO GAMING/AURA

dmesg:
2023-01-27T13:10:42+0100 kernel: nct6775: Enabling hardware monitor logical
device mappings.
2023-01-27T13:10:42+0100 kernel: nct6775: Found NCT6793D or compatible chip at
0x2e:0x290
2023-01-27T13:10:42+0100 kernel: ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20220331/utaddress-204)
2023-01-27T13:10:42+0100 kernel: ACPI: OSL: Resource conflict; ACPI support
missing from driver?

Setting acpi_enforce_resources=lax kernel parameter results in 'sensors'
returning much more data like fan speed, voltage etc.

Thank you for your work!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303655|0                           |1
        is obsolete|                            |

--- Comment #288 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303660
  --> https://bugzilla.kernel.org/attachment.cgi?id=303660&action=edit
Asus WMI for nct6775 v6.1 base (2023.01.28)

(In reply to Robert Kling from comment #287)
> Created attachment 303659 [details]
> dsdt.dat Z170 PRO GAMING/AURA
> 
> Hello, would it be possible to add support for Asus Z170 PRO GAMING/AURA?
> 
> cat /sys/class/dmi/id/board_name:
> Z170 PRO GAMING/AURA

Could you please check now? There will be used mutex lock for access to
sensors. 

Note, i have also checked such boards and it will be without support in any
currently known way as no mutex used inside access methods:
* Z170I PRO GAMING
* B150I PRO GAMING/WIFI/AURA
* B150I PRO GAMING/AURA 
* Z97-PRO GAMER (no definition like nct6775 sensor)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #289 from Robert Kling (robert.kling@gmail.com) ---
(In reply to Denis Pauk from comment #288)
> Created attachment 303660 [details]
> Asus WMI for nct6775 v6.1 base (2023.01.28)
> 
> (In reply to Robert Kling from comment #287)
> > Created attachment 303659 [details]
> > dsdt.dat Z170 PRO GAMING/AURA
> > 
> > Hello, would it be possible to add support for Asus Z170 PRO GAMING/AURA?
> > 
> > cat /sys/class/dmi/id/board_name:
> > Z170 PRO GAMING/AURA
> 
> Could you please check now? There will be used mutex lock for access to
> sensors. 
> 
> Note, i have also checked such boards and it will be without support in any
> currently known way as no mutex used inside access methods:
> * Z170I PRO GAMING
> * B150I PRO GAMING/WIFI/AURA
> * B150I PRO GAMING/AURA 
> * Z97-PRO GAMER (no definition like nct6775 sensor)

The patch didn't apply to 6.1.8 cleanly, some mainboards were already mentioned
in nct6775-platform.c. I tried to adapt and it applied/compiled.

But sensors show no fan speed & voltages.
dmesg showing:

2023-01-28T22:44:58+0100 kernel: nct6775: No such ASUS mutex: \_GPE.MUT0
2023-01-28T22:44:58+0100 kernel: nct6775: Enabling hardware monitor logical
device mappings.
2023-01-28T22:44:58+0100 kernel: nct6775: Found NCT6793D or compatible chip at
0x2e:0x290
2023-01-28T22:44:58+0100 kernel: ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20220331/utaddress-204)
2023-01-28T22:44:58+0100 kernel: ACPI: OSL: Resource conflict; ACPI support
missing from driver?

Not sure if I made an error, I'll try 6.1.0 when I have some more time.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303660|0                           |1
        is obsolete|                            |

--- Comment #290 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303662
  --> https://bugzilla.kernel.org/attachment.cgi?id=303662&action=edit
Asus WMI for nct6775 v6.1.8 base (2023.01.29)

(In reply to Robert Kling from comment #289)
> dmesg showing:
> 
> 2023-01-28T22:44:58+0100 kernel: nct6775: No such ASUS mutex: \_GPE.MUT0
> 2023-01-28T22:44:58+0100 kernel: nct6775: Enabling hardware monitor logical
> device mappings.
> 2023-01-28T22:44:58+0100 kernel: nct6775: Found NCT6793D or compatible chip
> at 0x2e:0x290
> 2023-01-28T22:44:58+0100 kernel: ACPI Warning: SystemIO range
> 0x0000000000000295-0x0000000000000296 conflicts with OpRegion
> 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20220331/utaddress-204)
> 2023-01-28T22:44:58+0100 kernel: ACPI: OSL: Resource conflict; ACPI support
> missing from driver?
> 
> Not sure if I made an error, I'll try 6.1.0 when I have some more time.

Could you try with such one?

Change with previous one is usage "\\_SB.PCI0.LPCB.SIO1.MUT0" mutex. Note - it
will be unsafe, looks like your board doesn't use/export mutex before access to
sensors and change settings of fans. So code just uses IO lock available in
dsdt.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #291 from Robert Kling (robert.kling@gmail.com) ---
(In reply to Denis Pauk from comment #290)
> Created attachment 303662 [details]
> Asus WMI for nct6775 v6.1.8 base (2023.01.29)
> 
> Could you try with such one?
> 
> Change with previous one is usage "\\_SB.PCI0.LPCB.SIO1.MUT0" mutex. Note -
> it will be unsafe, looks like your board doesn't use/export mutex before
> access to sensors and change settings of fans. So code just uses IO lock
> available in dsdt.

That seems to have done the trick!

kernel: nct6775: Using Asus WMI mutex: \_SB.PCI0.LPCB.SIO1.MUT0
kernel: nct6775: Enabling hardware monitor logical device mappings.
kernel: nct6775: Found NCT6793D or compatible chip at 0x2e:0x290

Not sure if more info from dmesg would be useful for you.

sensors is outputting fan/voltage data from nct6793-isa-0290 now!

I don't want to take up too much of your time for something that's not really
crucial, but how unsafe is it? I let the mainboard/bios handle cpu/aux fan
speed, I'm not running any fan control programs at the moment. Would that be
fine?

Thank you very much for your help & time!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #292 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Robert Kling from comment #291)
> I let the mainboard/bios handle
> cpu/aux fan speed, I'm not running any fan control programs at the moment.
> Would that be fine?

It depends on luck, bioses, hw schematic and so on. Main issue is bios does not
provide known methods for sensor access and does not use global mutex before
access to the region related to sensors, and mutual access could be not
possible with such bios implementation. It works without known issues for other
boards with mutex lock (P8H67, X99-E WS/USB 3.1). Other boards could have
issues, like example it can be such:
https://github.com/electrified/asus-wmi-sensors#known-issues. Its different
driver but issues could be the same.

> The WMI implementation in some of Asus' BIOSes is buggy. This can result in
> fans stopping, fans getting stuck at max speed, or temperature readouts
> getting stuck. This is not an issue with the driver, but the BIOS. The Prime
> X470 Pro seems particularly bad for this. The more frequently the WMI
> interface is polled the greater the potential for this to happen. Until you
> have subjected your computer to an extended soak test while polling the
> sensors frequently, don't leave you computer unattended. I can personally say
> I've seen the issue on the Crosshair VII with BIOS 2606 and a Ryzen 2700X,
> upgrading to 3004 rectified the issue.


Or https://bugzilla.kernel.org/show_bug.cgi?id=204807#c37

> Sensor hardware frequently uses indexed addressing, which means that
> accessing a sensor requires something like the following:
>
> 1) Write the desired sensor to the index register
> 2) Read the sensor value from the data register
>
> These can't occur simultaneously, so if both the OS and the firmware are
> accessing it you risk ending up with something like:

> 1) Write sensor A to the index register (from the OS)
> 2) Write sensor B to the index register (from the firmware)
> 3) Read the sensor value from the data register (returns the value of sensor
> B to the firmware)
> 4) Read the sensor value from the data register (returns the value of sensor
> B to the OS)


Or https://bugzilla.kernel.org/show_bug.cgi?id=204807#c69
> the lm_sensors sensors-detect script had overvolted his RAM ruining both his
> expensive high-end RAM as well as his expensive top of the line CPU. The user
> was surprisingly relaxed about all this, which I really appreciated.
>
> And that was while the script was not doing anything which we (the
> developers) considered dangerous. But the motherboard had a funky setup
> causing a SMbus *read* transaction to change the voltage.


Thank you!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #293 from Pär Ekholm (forum1@m.pekholm.org) ---
Is this stable on a 5.19 kernel? Having a TUF GAMING X570-PLUS board and hasn't
tried the patch before. Now I was getting the Ubuntu HWE kernel 5.19 for Jammy.
Can I run lm-sensors and having the sensors running without trouble?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #294 from Jeroen Beerstra (jeroen@beerstra.org) ---
For me, on 6.1 ML via elrepo. I needed to apply patch and modprobe nct6775.
Lmsensors did not detect my sensors. Other than that it just works :)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #295 from Pär Ekholm (forum1@m.pekholm.org) ---
(In reply to Jeroen Beerstra from comment #294)
> For me, on 6.1 ML via elrepo. I needed to apply patch and modprobe nct6775.
> Lmsensors did not detect my sensors. Other than that it just works :)

Isn't this patch included in kernels after 5.17?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #296 from A. M. (de99like@mennucci.debian.net) ---
(In reply to Jonathan from comment #103)
> Hi,
> (oh. Could've put my comment in the attachment comment... duh)
> I applied Denis Pauk patch today, (how I did it described in
> https://gist.github.com/greenbigfrog/26f948c9d86f1cb2fd23bfeaa23ca068 ).

hi I have updated the gist to compile on newer kernels >= 5.17 

https://gist.github.com/mennucc/2a322744612a7e21debfa001e987c15a

this gist does not patch; but anybody can add their MB to the whitelist easily

thanks

a.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #297 from Jeroen Beerstra (jeroen@beerstra.org) ---
ON 6.1.12 I still needed to apply it. Guess it’s included in 6.2 (RC atm)? But
I would love to stand corrected, compiling kernels goes like a tornado on a
highend Ryzen but still is a task I would like to skip nowadays...

> Op 16 feb. 2023, om 12:01 heeft bugzilla-daemon@kernel.org het volgende
> geschreven:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=204807
> 
> --- Comment #295 from Pär Ekholm (forum1@m.pekholm.org) ---
> (In reply to Jeroen Beerstra from comment #294)
>> For me, on 6.1 ML via elrepo. I needed to apply patch and modprobe nct6775.
>> Lmsensors did not detect my sensors. Other than that it just works :)
> 
> Isn't this patch included in kernels after 5.17?
> 
> -- 
> You may reply to this email to add a comment.
> 
> You are receiving this mail because:
> You are on the CC list for the bug.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #298 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Pär Ekholm from comment #293)
> Is this stable on a 5.19 kernel? Having a TUF GAMING X570-PLUS board and
> hasn't tried the patch before. Now I was getting the Ubuntu HWE kernel 5.19
> for Jammy. Can I run lm-sensors and having the sensors running without
> trouble?

You board is supported by 5.19 kernel, and does not have any know issues. Apply
additional patch is not required for your board.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hwmon/nct6775-platform.c?h=v5.19#n1090

After initial merge code does not have any significant changes related to asus
bioses support, just add new board to list of supported boards.

New kernel 6.3+ could have additional support of x670 boards. Merge window will
be in one or two weeks after that will be more information about exact list of
supported boards by upstream kernel.

Look to
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/tree/drivers/hwmon/nct6775-platform.c?h=hwmon-next#n1115 

Thank you.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #299 from A. M. (de99like@mennucci.debian.net) ---
hi all.
I have added my mobo a week ago to the list. It works fine. Someone may add it
to the whitelist. 

# cat /sys/class/dmi/id/board_name

PRIME A520M-A II

Thanks. a.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303662|0                           |1
        is obsolete|                            |

--- Comment #300 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303789
  --> https://bugzilla.kernel.org/attachment.cgi?id=303789&action=edit
Asus WMI for nct6775 v6.2 base (2023.02.26)

* Rebased over v6.2
* Added more AMD A520 boards.
* Several boards use different mutex name, could be regression - code is
unchecked for now.

(In reply to A. M. from comment #299)
> hi all.
> I have added my mobo a week ago to the list. It works fine. Someone may add
> it to the whitelist. 
> 
> # cat /sys/class/dmi/id/board_name
> 
> PRIME A520M-A II
> 
> Thanks. a.

Could you please recheck with new patch?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303789|0                           |1
        is obsolete|                            |

--- Comment #301 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303816
  --> https://bugzilla.kernel.org/attachment.cgi?id=303816&action=edit
Asus WMI for nct6775 v6.2 base (2023.02.28)

Add A320/B350/B760/Z590 boards.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Nick Owens (mischief@offblast.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mischief@offblast.org

--- Comment #302 from Nick Owens (mischief@offblast.org) ---
Created attachment 303833
  --> https://bugzilla.kernel.org/attachment.cgi?id=303833&action=edit
proart-x670e-dmi.patch

hi denis,

i've tested patch for 6.1.8
(https://bugzilla.kernel.org/show_bug.cgi?id=204807#c290) against gentoo 6.1.12
kernel on ProArt X670E-CREATOR WIFI. seems to work ok.

i attached a patch to put this board in asus_wmi_info_table, as this also
appears to make the module load automatically with a modalias. for the mutex, i
checked my DSDT and acpi_board_SBRG_MUTEX seems to exist there, but i am very
much a novice in kernel programming so i am unsure if this is correct. if it
helps i can attach my DSDT for this board.

i would very much like for this to be included in a future kernel, so if i can
help further let me know.

here is my sensor reading.

mischief@beast:~ $ dmesg|grep nct6775
[    6.678325] nct6775: Found NCT6799D or compatible chip at 0x2e:0x290
mischief@beast:~ $ sensors nct6799-*
nct6799-isa-0290
Adapter: ISA adapter
in0:                        1.34 V  (min =  +0.00 V, max =  +1.74 V)
in1:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.31 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                        1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                        1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                        1.15 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.30 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                        1.66 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     528.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     528.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                       1.28 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                       1.23 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                        0 RPM  (min =    0 RPM)
fan2:                      849 RPM  (min =    0 RPM)
fan3:                      841 RPM  (min =    0 RPM)
fan4:                        0 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +37.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
CPUTIN:                    +41.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
thermistor
AUXTIN0:                   +18.0°C    sensor = thermistor
AUXTIN1:                   +23.0°C    sensor = thermistor
AUXTIN2:                   +23.0°C    sensor = thermistor
AUXTIN3:                   +14.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +41.5°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
PCH_CPU_TEMP:               +0.0°C  
TSI0_TEMP:                 +50.5°C  
intrusion0:               OK
intrusion1:               ALARM
beep_enable:              disabled

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

barfin@protonmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |barfin@protonmail.com

--- Comment #303 from barfin@protonmail.com ---
I'm Using ASUS H97-ProGamer motherboard and i still can't sensors on kernel
6.2.2 without using "acpi_enforce_resources=lax", i haven't seen anyone else
mention the asus-h97-progamer motherboard but this mb is having the same issue
as all others that were mentioned

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #304 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to barfin from comment #303)
> I'm Using ASUS H97-ProGamer motherboard and i still can't sensors on kernel
> 6.2.2 without using "acpi_enforce_resources=lax", i haven't seen anyone else
> mention the asus-h97-progamer motherboard but this mb is having the same
> issue as all others that were mentioned

Uefi dump of H97 board does not have any known APIs, Could you please check
what sensor is detected on board after "acpi_enforce_resources=lax"? it can be
showed in dmesg/sensors output or in dmidecode output.

(In reply to Nick Owens from comment #302)
(In reply to A. M. from comment #299)
Thank you, I have found issues in my script for detect available port
definitions/methods in UEFI dump. I will send patch to upstream with new boards
after fix issues and rescan board dumps.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #305 from barfin@protonmail.com ---
(In reply to Denis Pauk from comment #304)
> (In reply to barfin from comment #303)
> > I'm Using ASUS H97-ProGamer motherboard and i still can't sensors on kernel
> > 6.2.2 without using "acpi_enforce_resources=lax", i haven't seen anyone
> else
> > mention the asus-h97-progamer motherboard but this mb is having the same
> > issue as all others that were mentioned
> 
> Uefi dump of H97 board does not have any known APIs, Could you please check
> what sensor is detected on board after "acpi_enforce_resources=lax"? it can
> be showed in dmesg/sensors output or in dmidecode output.
> 
> (In reply to Nick Owens from comment #302)
> (In reply to A. M. from comment #299)
> Thank you, I have found issues in my script for detect available port
> definitions/methods in UEFI dump. I will send patch to upstream with new
> boards after fix issues and rescan board dumps.

here's all the outputs, the file that have "_lax" at the end were captured when
acpi_enforce_resources=lax was used
https://drive.proton.me/urls/8S727K80A4#MdPfNfkyxSbq

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #306 from barfin@protonmail.com ---
Created attachment 303946
  --> https://bugzilla.kernel.org/attachment.cgi?id=303946&action=edit
ASUS H97-Progamer sensors output with acpi_enforce_resources=lax

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #307 from barfin@protonmail.com ---
Created attachment 303947
  --> https://bugzilla.kernel.org/attachment.cgi?id=303947&action=edit
ASUS H97-Progamer dmesg

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303816|0                           |1
        is obsolete|                            |

--- Comment #308 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303968
  --> https://bugzilla.kernel.org/attachment.cgi?id=303968&action=edit
Asus WMI for nct6775 v6.2 base (2023.03.16)

Clean up previous patch, add more boards.

(In reply to barfin from comment #305)
> 
> here's all the outputs, the file that have "_lax" at the end were captured
> when acpi_enforce_resources=lax was used
> https://drive.proton.me/urls/8S727K80A4#MdPfNfkyxSbq

Could you please check messages in dmesg without lax about resource conflicts?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #309 from Jeroen Beerstra (jeroen@beerstra.org) ---
(In reply to Denis Pauk from comment #308)
> Created attachment 303968 [details]
> Asus WMI for nct6775 v6.2 base (2023.03.16)
> 
> Clean up previous patch, add more boards.
> 

How do I apply this patch to 6.2.6? It reports:
Reversed (or previously applied) patch detected!  Assume -R?

And not all changes apply :/

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303968|0                           |1
        is obsolete|                            |

--- Comment #310 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303973
  --> https://bugzilla.kernel.org/attachment.cgi?id=303973&action=edit
Asus WMI for nct6775 v6.2.7 base (2023.03.17)

(In reply to Jeroen Beerstra from comment #309)
> (In reply to Denis Pauk from comment #308)
> > Created attachment 303968 [details]
> > Asus WMI for nct6775 v6.2 base (2023.03.16)
> > 
> > Clean up previous patch, add more boards.
> > 
> 
> How do I apply this patch to 6.2.6? It reports:
> Reversed (or previously applied) patch detected!  Assume -R?
> 
> And not all changes apply :/
Could you please check new one ? I have rebased patch to 6.2.7

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #311 from Jeroen Beerstra (jeroen@beerstra.org) ---
(In reply to Denis Pauk from comment #310)
> Could you please check new one ? I have rebased patch to 6.2.7

Applies, compiles, and works just fine. Thank you very much for your hard work,
hope all of this lands in 6.3.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #312 from renedis (renedis@hotmail.com) ---
Please also add:

cat /sys/class/dmi/id/board_name
Pro H610T D4


It's the same board (and uses the same chip) as the H410T but with a newer 1700
socket.

Thanks again!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303973|0                           |1
        is obsolete|                            |

--- Comment #313 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 303985
  --> https://bugzilla.kernel.org/attachment.cgi?id=303985&action=edit
Asus WMI for nct6775 v6.2.7 base (2023.03.20)

Added additional boards based on data from
https://github.com/linuxhw/ACPI/tree/master/Desktop/ASUSTek%20Computer

(In reply to renedis from comment #312)
> Please also add:
> 
> cat /sys/class/dmi/id/board_name
> Pro H610T D4
> 
> 
> It's the same board (and uses the same chip) as the H410T but with a newer
> 1700 socket.
> 
> Thanks again!
Thank you!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #314 from barfin@protonmail.com ---
(In reply to Denis Pauk from comment #308)
> Created attachment 303968 [details]
> Asus WMI for nct6775 v6.2 base (2023.03.16)
> 
> Clean up previous patch, add more boards.
> 
> (In reply to barfin from comment #305)
> > 
> > here's all the outputs, the file that have "_lax" at the end were captured
> > when acpi_enforce_resources=lax was used
> > https://drive.proton.me/urls/8S727K80A4#MdPfNfkyxSbq
> 
> Could you please check messages in dmesg without lax about resource
> conflicts?

sure
https://gist.github.com/barfin/943c219a5a6bd8aa15778d8c80b2786c

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

bruno (bmilreu@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bmilreu@gmail.com

--- Comment #315 from bruno (bmilreu@gmail.com) ---
Created attachment 304004
  --> https://bugzilla.kernel.org/attachment.cgi?id=304004&action=edit
acpidump -b for ROG STRIX Z690-E GAMING WIFI

acpidump -b for the ROG STRIX Z690-E GAMING WIFI

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #316 from bruno (bmilreu@gmail.com) ---
Created attachment 304005
  --> https://bugzilla.kernel.org/attachment.cgi?id=304005&action=edit
dmidecode for ROG STRIX Z690-E GAMING WIFI

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #317 from Alejandro González (alejandro.gonzalez.correo@gmail.com) ---
Created attachment 304010
  --> https://bugzilla.kernel.org/attachment.cgi?id=304010&action=edit
ASUS PRIME Z690-P ACPI table dump (acpidump -b)

I'm attaching the ACPI table dump of an ASUS PRIME Z690-P board. As far as I
can see it uses the classic WMI method, so it should work by adding it to the
asus_wmi_boards list at nct6775-platform.c.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #303985|0                           |1
        is obsolete|                            |

--- Comment #318 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 304011
  --> https://bugzilla.kernel.org/attachment.cgi?id=304011&action=edit
Asus WMI for nct6775 v6.2.7 base (2023.03.23)

Updated version of the patch with more boards. 

Full list of boards:
https://github.com/asus-wmi-boards-sensors/asus-board-dsdt/blob/master/README.md

(In reply to barfin from comment #314)
> 
> sure
> https://gist.github.com/barfin/943c219a5a6bd8aa15778d8c80b2786c
Thank you, I dont see any suspicious conflicts, could you please try load
sensor module and check errors on load with lax.

(In reply to bruno from comment #316)
> Created attachment 304005 [details]
> dmidecode for ROG STRIX Z690-E GAMING WIFI
(In reply to Alejandro González from comment #317)
> Created attachment 304010 [details]
> ASUS PRIME Z690-P ACPI table dump (acpidump -b)
Thank you, I will add boards to next upstream patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #319 from Jeroen Beerstra (jeroen@beerstra.org) ---
(In reply to Jeroen Beerstra from comment #311)
> (In reply to Denis Pauk from comment #310)
> > Could you please check new one ? I have rebased patch to 6.2.7
> 
> Applies, compiles, and works just fine. Thank you very much for your hard
> work, hope all of this lands in 6.3.

Same for 6.2.8. I did notice these warnings though:

drivers/hwmon/nct6775-platform.c:1325:21: warning: 'acpi_board_0LPC_MUTEX'
defined but not used [-Wunused-variable]
 1325 | DMI_ASUS_BOARD_INFO(acpi_board_0LPC_MUTEX,
"\\_SB.PC00.LPCB.SIO1.MUT0");
      |                     ^~~~~~~~~~~~~~~~~~~~~
drivers/hwmon/nct6775-platform.c:1319:31: note: in definition of macro
'DMI_ASUS_BOARD_INFO'
 1319 | static struct acpi_board_info name = {                          \
      |                               ^~~~
drivers/hwmon/nct6775-platform.c:1324:21: warning: 'acpi_board_LPCB_MUTEX'
defined but not used [-Wunused-variable]
 1324 | DMI_ASUS_BOARD_INFO(acpi_board_LPCB_MUTEX,
"\\_SB_.PCI0.LPCB.SIO1.MUT0");
      |                     ^~~~~~~~~~~~~~~~~~~~~
drivers/hwmon/nct6775-platform.c:1319:31: note: in definition of macro
'DMI_ASUS_BOARD_INFO'
 1319 | static struct acpi_board_info name = {                          \
      |                               ^~~~
drivers/hwmon/nct6775-platform.c:1323:21: warning: 'acpi_board_GPEM_MUTEX'
defined but not used [-Wunused-variable]
 1323 | DMI_ASUS_BOARD_INFO(acpi_board_GPEM_MUTEX, "\\_GPE.MUT0");
      |                     ^~~~~~~~~~~~~~~~~~~~~
drivers/hwmon/nct6775-platform.c:1319:31: note: in definition of macro
'DMI_ASUS_BOARD_INFO'
 1319 | static struct acpi_board_info name = {                          \
      |                               ^~~~

Since they seem pretty harmless to me, I didn't report them earlier.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Mickaël Blanchard (mblancha@free.fr) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mblancha@free.fr

--- Comment #320 from Mickaël Blanchard (mblancha@free.fr) ---
Hi,

I wonder why the board B550M-K has disappeared from the final patch integrated
in the kernel sources. It's somewhat the same board as B550M-A, which is
included.
Moreover, it's in the list in comment #278:
https://bugzilla.kernel.org/show_bug.cgi?id=204807#c278

An unfortunate omission? :)

Thanks!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #304011|0                           |1
        is obsolete|                            |

--- Comment #321 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 304071
  --> https://bugzilla.kernel.org/attachment.cgi?id=304071&action=edit
Asus WMI for nct6775 v6.2.9 base (2023.04.01)

Updated patch version.

(In reply to Mickaël Blanchard from comment #320)
> Hi,
> 
> I wonder why the board B550M-K has disappeared from the final patch
> integrated in the kernel sources. It's somewhat the same board as B550M-A,
> which is included.
> Moreover, it's in the list in comment #278:
> https://bugzilla.kernel.org/show_bug.cgi?id=204807#c278
> 
> An unfortunate omission? :)
> 
> Thanks!

Do you mean "PRIME B550M-K"? Both hwmon-next branch and patch have it in
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/tree/drivers/hwmon/nct6775-platform.c?h=hwmon-next&id=8a863eb1b1162653d133856702e13560f3596b85#n1076

Do you have some load issue with new patch?  

(In reply to Jeroen Beerstra from comment #319)
> (In reply to Jeroen Beerstra from comment #311)
> > (In reply to Denis Pauk from comment #310)
> > > Could you please check new one ? I have rebased patch to 6.2.7
> > 
> > Applies, compiles, and works just fine. Thank you very much for your hard
> > work, hope all of this lands in 6.3.
> 
> Same for 6.2.8. I did notice these warnings though:
Thank you, should be fixed in new patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #322 from Mickaël Blanchard (mblancha@free.fr) ---
> (In reply to Mickaël Blanchard from comment #320)
> > Hi,
> > 
> > I wonder why the board B550M-K has disappeared from the final patch
> > integrated in the kernel sources. It's somewhat the same board as B550M-A,
> > which is included.
> > Moreover, it's in the list in comment #278:
> > https://bugzilla.kernel.org/show_bug.cgi?id=204807#c278
> > 
> > An unfortunate omission? :)
> > 
> > Thanks!
> 
> Do you mean "PRIME B550M-K"? Both hwmon-next branch and patch have it in
> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/
> tree/drivers/hwmon/nct6775-platform.c?h=hwmon-
> next&id=8a863eb1b1162653d133856702e13560f3596b85#n1076
> 
> Do you have some load issue with new patch?  

Yes this is the board I'm talking about.
I'm currently running 6.1.21 and the board is not included here. So I still
have the load issue.
I haven't watched in the staging, I should have as indeed it's here. :)
So I guess I just have to wait the merge & backport in 6.1 branch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #323 from Jeroen Beerstra (jeroen@beerstra.org) ---
Op 01-04-2023 om 15:09 schreef bugzilla-daemon@kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=204807
>
> Denis Pauk (pauk.denis@gmail.com) changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>   Attachment #304011|0                           |1
>          is obsolete|                            |
>
> --- Comment #321 from Denis Pauk (pauk.denis@gmail.com) ---
> Created attachment 304071
>    --> https://bugzilla.kernel.org/attachment.cgi?id=304071&action=edit
> Asus WMI for nct6775 v6.2.9 base (2023.04.01)
>
> Updated patch version.
>
>
> (In reply to Jeroen Beerstra from comment #319)
>> (In reply to Jeroen Beerstra from comment #311)
>>> (In reply to Denis Pauk from comment #310)
>>>> Could you please check new one ? I have rebased patch to 6.2.7
>>> Applies, compiles, and works just fine. Thank you very much for your hard
>>> work, hope all of this lands in 6.3.
>> Same for 6.2.8. I did notice these warnings though:
> Thank you, should be fixed in new patch.

Yes it is, thank you.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #304071|0                           |1
        is obsolete|                            |

--- Comment #324 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 304077
  --> https://bugzilla.kernel.org/attachment.cgi?id=304077&action=edit
Asus WMI for nct6775 v6.2.9 base (2023.04.02)

Added A620 several boards which have uefi bios download link on official site. 

(In reply to barfin from comment #314)
> (In reply to Denis Pauk from comment #308)
I have added ugly hack for skip resource conflicts on "H97-PRO GAMER".
Could you please check that it works for your case?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #304077|0                           |1
        is obsolete|                            |

--- Comment #325 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 304087
  --> https://bugzilla.kernel.org/attachment.cgi?id=304087&action=edit
Asus WMI for nct6775 v6.2.9 base (2023.04.05)

Add more H310/H370/H410 boards

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #326 from Jeroen Beerstra (jeroen@beerstra.org) ---
Any news on 6.3 which has been released? Cannot move as of yet because zfs is
not ready for 6.3 also :) Just curious, before I moved my main storage array to
zfs I did boot with 6.3 and noticed my fans and temp sensors were gone again ;)
I do appreaciate your efforts though, we depend on people like you to get our
precious new hardware supported on Linux .... if only companies like Asus would
look beyond M$ Windows.

Then again, we would have the same bloatware on our beloved Linux too :D

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Denis Pauk (pauk.denis@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #304087|0                           |1
        is obsolete|                            |

--- Comment #327 from Denis Pauk (pauk.denis@gmail.com) ---
Created attachment 304223
  --> https://bugzilla.kernel.org/attachment.cgi?id=304223&action=edit
Asus WMI for nct6775 v6.3 base (2023.05.06)

Rebased over v6.3, List of supported boards are same as previous.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Jannik Glückert (jannik.glueckert@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jannik.glueckert@gmail.com

--- Comment #328 from Jannik Glückert (jannik.glueckert@gmail.com) ---
Created attachment 304249
  --> https://bugzilla.kernel.org/attachment.cgi?id=304249&action=edit
ASUS TUF B650M-PLUS WIFI

Hi, is this the correct place to also report issues with the new ASUS NCT6799D
support in kernel 6.3?

I'm on an ASUS TUF GAMING B650M-PLUS WIFI , kernel 6.3.1

Trying to modprobe nct6775 fails with ENODEV, doing so with force_id=0xd428
works:
[ 1600.922632] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[ 1600.931439] nct6775: Refusing to enable a Super-I/O device with a base I/O
port 0

However, all sensor values are unlabeled.

Or did I misunderstand, and NCT6799D is not meant to be fully supported yet?

Attached are dmidecode, acpidump, and the readings from sensors.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #329 from Denis Pauk (pauk.denis@gmail.com) ---
(In reply to Jannik Glückert from comment #328)
> Created attachment 304249 [details]
> ASUS TUF B650M-PLUS WIFI
> 
> Hi, is this the correct place to also report issues with the new ASUS
> NCT6799D support in kernel 6.3?
> 
> I'm on an ASUS TUF GAMING B650M-PLUS WIFI , kernel 6.3.1
> 
> Trying to modprobe nct6775 fails with ENODEV, doing so with force_id=0xd428
> works:
> [ 1600.922632] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
> [ 1600.931439] nct6775: Refusing to enable a Super-I/O device with a base
> I/O port 0
> 
> However, all sensor values are unlabeled.
> 
> Or did I misunderstand, and NCT6799D is not meant to be fully supported yet?
> 
> Attached are dmidecode, acpidump, and the readings from sensors.

Upstream code has support for asus boards with such sensor. In same time
upstream code does not have support for sensor itself. And need to apply
additional patch from
https://patchwork.kernel.org/project/linux-hwmon/patch/20221228135744.281752-1-linux@roeck-us.net/.

Patch from comment #327 also contains this patch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

--- Comment #330 from Gregory Duhamel (gregory.duhamel@gmail.com) ---
Hello,

i've this board : 

Base Board Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: ROG STRIX X670E-I GAMING WIFI

But no sensors are detect on Kernel : 6.3.3-200 (Fedora)

Can someone please help me understand where is the issue (if any) ?

Thanks a lot !

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

zurabid2016@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zurabid2016@gmail.com

--- Comment #331 from zurabid2016@gmail.com ---
Hey, I use 6.3.9 custom kernel on Gentoo GNU/Linux and it seems that my
motherboard is not (yet) supported. It is TUF GAMING B460-PLUS. I looked at
6.4.0 sources and.. voila it is there. Will wait for the next stable release,
then

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

Dmitry (bugzilla@svhs.ru) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@svhs.ru

--- Comment #332 from Dmitry (bugzilla@svhs.ru) ---
Hello,
i've this board : 
Base Board Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: X99-A II

# dmesg|tail -n 3
[431341.603491] nct6775: Found NCT6791D or compatible chip at 0x2e:0x290
[431341.603501] ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20210730/utaddress-204)
[431341.603510] ACPI: OSL: Resource conflict; ACPI support missing from driver?

Sensors not found, add support for access to nct6775
Thanks a lot !

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

zemerdon@hotmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zemerdon@hotmail.com

--- Comment #333 from zemerdon@hotmail.com ---
Created attachment 305675
  --> https://bugzilla.kernel.org/attachment.cgi?id=305675&action=edit
no T_SENSOR for ASUS WS X299 SAGE/10 DSDT.dsl

       Product Name: WS X299 SAGE/10G
        Version: Rev 1.xx

Good morning,

I have a single thermistor attached to the T_SENSOR on the motherboard which
shows up in the BIOS no problem.  Is there a way to get this to show up in
lm-sensors or possibly provide information to help development to add this
sensor ?

I have also added "GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax" with no
changes.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

zemerdon@hotmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #305675|0                           |1
        is obsolete|                            |

--- Comment #334 from zemerdon@hotmail.com ---
Created attachment 305676
  --> https://bugzilla.kernel.org/attachment.cgi?id=305676&action=edit
no T_SENSOR for ASUS WS X299 SAGE/10 DSDT.aml DSDT.dsl

Product Name: WS X299 SAGE/10G
Version: Rev 1.xx

Good morning,

I have a single thermistor attached to the T_SENSOR on the motherboard which
shows up in the BIOS no problem.  Is there a way to get this to show up in
lm-sensors or possibly provide information to help development to add this
sensor ?

I have also added "GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax" with no
changes.

Not sure if this is the right place for this, if it isn't could someone please
direct me to the right place.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=204807

zerofixgiven (felix.schmidtpeter@yahoo.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |felix.schmidtpeter@yahoo.de

--- Comment #335 from zerofixgiven (felix.schmidtpeter@yahoo.de) ---
(In reply to Denis Pauk from comment #265)
> (In reply to zykr.caswell from comment #264)
> > Created attachment 303116 [details]
> > DSDT - X99-E-WS-USB3 - Decompiled
> > 
> > Same or similar issue with X99-E WS/USB 3.1:
> > 
> > nct6775: Found NCT6791D or compatible chip at 0x2e:0x290
> > ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296
> conflicts
> > with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM)
> > (20200925/utaddress-204)
> > 
> > I've been trying to make sense of the DSDT by reading the ACPI spec, but
> I'm
> > not having a lot success. Built kernels 5.10, 5.19, 6.0.2, 6.03, and
> several
> > different versions of nct6775 driver for each including "Asus WMI for
> > nct6775 v5.20 base (2022.10.20)", both in tree and as a custom DKMS module
> > to no effect.
> > 
> > I'm rather reluctant to actually try using acpi_enforce_resourses=lax, so I
> > don't know for sure if that would make it work or not. I've attached my
> DSDT
> > as pulled from the latest BIOS update for my board from ASUS. Could someone
> > take a look and confirm for me that I likely have this same problem?
> 
> Could you please apply patch and add line with you board and recheck? Change
> should be like "DMI_MATCH_ASUS_WMI_BOARD("<You board name>",
> &acpi_board_LPCB_MUTEX)," near "MAXIMUS VII HERO" definition.
> 
> Name board should be from /sys/class/dmi/id/board_name.

I would like to ask if the support for the board "MAXIMUS VII HERO" will be
merged to the kernel in the future?
If any assistance for testing is needed I am happy to help to get this added.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.