Hi Eugene,
I see. Thank you.
On Thu, 16 Dec 2021 23:58:40 +0100
Eugene Shalygin <eugene.shalygin@xxxxxxxxx> wrote:
> 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
Best regards,
Denis.
