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

[bugzilla-daemon@bugzilla.kernel.org]

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.