Hi Denis, On Thu, 16 Dec 2021 at 23:04, Denis Pauk <pauk.denis@xxxxxxxxx> wrote: > > Hi Eugene, > > Have you found some issues with idea of usage ACPI WMI methods as > failback solution, like in case when ASUS will release some BIOS with > different mutex path or different motherboard where will be same WMI > methods but fully different internal logic? Not direct ones, but yes. First of all, I still don't understand what causes the big slowdown in ec_read() calls. I learned that Fedora and Arch kernel configs result in the slowdown, while my custom minimal kernel does not (well, it is still slow but nevertheless). I tried to unload all the modules I do not have in my custom kernel, I tried to disable every option which is related to ACPI in the Fedora config, but the slowdown did not disappear. Then it is not that simple to gather information from other users, because one needs the ec_sys module to measure ec_read() performance, but it is not available in many distribution kernels it seems. Instead of that I've changed data structures for board description to include the mutex path there, so that we can handle various paths or version dependent paths for each motherboard. I can add code to select the mutex path based on the BIOS version for the next iteration. Also considering adding a module parameter to override that path. I think that will be maintainable and give users a way for a local fix while waiting for kernel update. Would you agree? That way, I believe, the WMI fallback is rendered barely useful and I decided to drop it. Best regards, Eugene
