From: Denis Pauk <pauk.denis@gmail.com>
To: Eugene Shalygin <eugene.shalygin@gmail.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
Jean Delvare <jdelvare@suse.com>,
Guenter Roeck <linux@roeck-us.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-hwmon@vger.kernel.org
Subject: Re: [PATCH 1/3] hwmon: (asus-ec-sensors) add driver for ASUS EC
Date: Sat, 18 Dec 2021 20:48:39 +0200 [thread overview]
Message-ID: <20211218204839.609bf329@netbook-debian> (raw)
In-Reply-To: <CAB95QAQs5=t37UTv2r=ewj1QaaD5LQckGXG1zL+wWYxYTgBdtA@mail.gmail.com>
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.
next prev parent reply other threads:[~2021-12-18 18:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-16 20:53 [PATCH 1/3] hwmon: (asus-ec-sensors) add driver for ASUS EC Eugene Shalygin
2021-12-16 20:53 ` [PATCH 2/3] hwmon: update ASUS EC driver documentation Eugene Shalygin
2021-12-16 20:53 ` [PATCH 3/3] hwmon: remove asus_wmi_ec_sensors driver Eugene Shalygin
2021-12-16 21:40 ` Denis Pauk
2021-12-16 21:27 ` [PATCH 1/3] hwmon: (asus-ec-sensors) add driver for ASUS EC Andy Shevchenko
2021-12-16 22:04 ` Denis Pauk
2021-12-16 22:58 ` Eugene Shalygin
2021-12-18 18:48 ` Denis Pauk [this message]
2021-12-17 0:07 ` Eugene Shalygin
2021-12-17 4:35 ` kernel test robot
2021-12-17 4:35 ` kernel test robot
-- strict thread matches above, loose matches on Subject: below --
2021-12-17 16:43 PATCH v2 ASUS EC Sensors Eugene Shalygin
2021-12-17 16:43 ` [PATCH 1/3] hwmon: (asus-ec-sensors) add driver for ASUS EC Eugene Shalygin
2021-12-17 21:34 ` kernel test robot
2021-12-17 21:52 ` Guenter Roeck
2021-12-17 22:33 ` Eugene Shalygin
2021-12-17 23:47 ` Guenter Roeck
2022-01-11 16:08 PATCH v3 ASUS EC Sensors Eugene Shalygin
2022-01-11 16:08 ` [PATCH 1/3] hwmon: (asus-ec-sensors) add driver for ASUS EC Eugene Shalygin
2022-01-11 16:33 ` Guenter Roeck
2022-01-11 17:04 ` Guenter Roeck
2022-01-11 17:22 ` Eugene Shalygin
2022-01-11 18:43 ` Guenter Roeck
2022-01-11 18:52 ` Eugene Shalygin
2022-01-11 19:15 ` Guenter Roeck
2022-01-11 19:18 ` Eugene Shalygin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211218204839.609bf329@netbook-debian \
--to=pauk.denis@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=eugene.shalygin@gmail.com \
--cc=jdelvare@suse.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.