All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Eugene Shalygin <eugene.shalygin@gmail.com>,
	Denis Pauk <pauk.denis@gmail.com>
Cc: andy.shevchenko@gmail.com, Jean Delvare <jdelvare@suse.com>,
	linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v2 2/3] hwmon: (asus_wmi_ec_sensors) Support B550 Asus WMI.
Date: Sun, 10 Oct 2021 07:33:04 -0700	[thread overview]
Message-ID: <8527fb83-4b76-e3c4-85eb-542c1cee249a@roeck-us.net> (raw)
In-Reply-To: <CAB95QAQs_PUeTU7d9tg83a8hRepjLfLnxVykU2nvBv3Vn49HBQ@mail.gmail.com>

On 10/10/21 6:46 AM, Eugene Shalygin wrote:
> Hi Denis,
> 
> On Sun, 10 Oct 2021 at 12:39, Denis Pauk <pauk.denis@gmail.com> wrote:
>>
>> Hi Eugene,
>>
>> As for me, use WMI methods will be more reliable and cover more
>> motherboards.
> 
> Why do you believe they are more reliable? How does it cover more motherboards?
> 

You said yourself below: "I know the naive reading from the ACPI EC registers
leads to problems (fans get stuck, etc.)".

Something in the WMI code is obviously broken and, ultimately, will need
to get fixed. I don't know if that something is on the ASUS side or on the
kernel side, or on the interface between the two. A single WMI call taking
1 second is way too long and strongly suggests that some timeout is involved.
Not using WMI because of that just seems wrong.

Guenter

> Thanks,
> Eugene
> 
>>
>> Best regards,
>>              Denis.
>>
>> On Thu, 7 Oct 2021 20:11:33 +0200
>> Eugene Shalygin <eugene.shalygin@gmail.com> wrote:
>>
>>> Denis and All,
>>>
>>> regarding the asus-wmi-ec-sensors driver: it uses a WMI method to read
>>> EC registers, and this method is slow (requires almost a full second
>>> for a single call). Maybe I'm doing something wrong, but my impression
>>> is that the WMI calls themselves are that slow. I will try to
>>> reimplement this driver using direct EC operations and the global ACPI
>>> lock with a hope to make it read sensors quicker. If that works out,
>>> perhaps the nct6775 may go the same way, as it suffers too from the
>>> slow WMI calls. I know next to nothing about the ACPI system and learn
>>> from the beginning, so I'm not sure about the result. I know the naive
>>> reading from the ACPI EC registers leads to problems (fans get stuck,
>>> etc.), and if someone with knowledge can assure me that the idea with
>>> the ACPI global lock (as far as I understand it is even implemented in
>>> the ec kernel driver already) is correct, I would even request to stop
>>> accepting the EC WMI sensors driver, as it is so slow (albeit dead
>>> simple and small).
>>>
>>> Best regards,
>>> Eugen
>>>


  reply	other threads:[~2021-10-10 14:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06 22:24 [PATCH v2 0/3] [PATCH v2 0/3] Update ASUS WMI supported boards Denis Pauk
2021-10-06 22:24 ` [PATCH v2 1/3] hwmon: (nct6775) Add additional ASUS motherboards Denis Pauk
2021-10-07 10:35   ` Oleksandr Natalenko
2021-10-06 22:25 ` [PATCH v2 2/3] hwmon: (asus_wmi_ec_sensors) Support B550 Asus WMI Denis Pauk
2021-10-06 23:32   ` Eugene Shalygin
2021-10-07 15:46     ` Denis Pauk
2021-10-07 17:55       ` Eugene Shalygin
2021-10-07 18:11         ` Eugene Shalygin
2021-10-09 15:44           ` Eugene Shalygin
2021-10-10 10:39           ` Denis Pauk
2021-10-10 13:46             ` Eugene Shalygin
2021-10-10 14:33               ` Guenter Roeck [this message]
2021-10-10 18:45                 ` Eugene Shalygin
2021-10-25 13:10                   ` Eugene Shalygin
2021-10-07 16:41   ` Guenter Roeck
2021-10-07 17:17     ` Denis Pauk
2021-10-07 16:47   ` Guenter Roeck
2021-10-07 17:14     ` Denis Pauk
2021-10-08 14:42   ` Eugene Shalygin
2021-10-06 22:25 ` [PATCH v2 3/3] hwmon: (asus_wmi_sensors) Support X370 " Denis Pauk
2021-10-07 10:56   ` Eugene Shalygin
2021-10-07 15:36     ` Denis Pauk
2021-10-07 16:45   ` Guenter Roeck

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=8527fb83-4b76-e3c4-85eb-542c1cee249a@roeck-us.net \
    --to=linux@roeck-us.net \
    --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=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.