https://bugzilla.kernel.org/show_bug.cgi?id=204807 Denis Pauk (pauk.denis@xxxxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #299517|0 |1 is obsolete| | --- Comment #169 from Denis Pauk (pauk.denis@xxxxxxxxx) --- 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.
