[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 #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.