Messages in this thread | | | Date | Sat, 18 Dec 2021 20:48:39 +0200 | From | Denis Pauk <> | Subject | Re: [PATCH 1/3] hwmon: (asus-ec-sensors) add driver for ASUS EC |
| |
Hi Eugene,
I see. Thank you.
On Thu, 16 Dec 2021 23:58:40 +0100 Eugene Shalygin <eugene.shalygin@gmail.com> wrote:
> Hi Denis, > > On Thu, 16 Dec 2021 at 23:04, Denis Pauk <pauk.denis@gmail.com> 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
Best regards, Denis.
| |