linux-kernel - Re: [PATCH 1/3] hwmon: (asus-ec-sensors) add driver for ASUS EC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 Dec 2021 23:58:40 +0100
From:   Eugene Shalygin <eugene.shalygin@...il.com>
To:     Denis Pauk <pauk.denis@...il.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Jean Delvare <jdelvare@...e.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-hwmon@...r.kernel.org
Subject: Re: [PATCH 1/3] hwmon: (asus-ec-sensors) add driver for ASUS EC

Hi Denis,

On Thu, 16 Dec 2021 at 23:04, Denis Pauk <pauk.denis@...il.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