https://bugzilla.kernel.org/show_bug.cgi?id=204807 --- Comment #170 from Eugene Shalygin (eugene.shalygin@xxxxxxxxx) --- (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.
