All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugene Shalygin <eugene.shalygin@gmail.com>
To: Denis Pauk <pauk.denis@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: Thu, 16 Dec 2021 23:58:40 +0100	[thread overview]
Message-ID: <CAB95QAQs5=t37UTv2r=ewj1QaaD5LQckGXG1zL+wWYxYTgBdtA@mail.gmail.com> (raw)
In-Reply-To: <20211217000424.41da446e@netbook-debian>

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

  reply	other threads:[~2021-12-16 22:58 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 [this message]
2021-12-18 18:48       ` Denis Pauk
2021-12-17  0:07   ` Eugene Shalygin
2021-12-17  4:35 ` kernel test robot
2021-12-17  4:35   ` kernel test robot
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='CAB95QAQs5=t37UTv2r=ewj1QaaD5LQckGXG1zL+wWYxYTgBdtA@mail.gmail.com' \
    --to=eugene.shalygin@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=jdelvare@suse.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=pauk.denis@gmail.com \
    /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.