public inbox for linux-hwmon@vger.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Denis Pauk <pauk.denis@gmail.com>
Cc: eugene.shalygin@gmail.com, andy.shevchenko@gmail.com,
	platform-driver-x86@vger.kernel.org,
	Jean Delvare <jdelvare@suse.com>,
	linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/3] hwmon: (nct6775) Support lock by ACPI mutex
Date: Fri, 17 Dec 2021 08:22:58 -0800	[thread overview]
Message-ID: <c6bf6ce9-8b45-e4a2-7167-83bdc8437fca@roeck-us.net> (raw)
In-Reply-To: <20211217002223.63b1e0a7@netbook-debian>

On 12/16/21 2:22 PM, Denis Pauk wrote:
> Hi,
> 
> Could you please provide a some feedback about such idea?
> 
> I have bigger list of supported boards that requires ACPI mutex lock,
> but I prefer to have some feedback before send next version of patch.
> 
> I have created separate patch[1] with only boards where WMI methods is
> enough. And if work on patch takes some time/additional patch
> versions(for sure it will), I prefer to have that patch merged and
> rebase current patch over resulted list of boards.
> 

Looking through the code, I am absolutely not happy with it. It makes
the driver even more unreadable than it already is, and on top of that
makes it vulnerable to problems in the ACPI code. Example: If ACPI fails
to unlock the mutex, the driver will end up being non-functional.

At some point, we have to face it: ASUS doesn't support Linux, and they
make it hard to access chips like this. I think the chip should be
accessed through "official" channels only if provided (ie WMI/ACPI),
or not at all.

Guenter

  reply	other threads:[~2021-12-17 16:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-28 18:45 [PATCH v2 0/3] hwmon: (nct6775) Support lock by ACPI mutex Denis Pauk
2021-11-28 18:45 ` [PATCH v2 1/3] hwmon: (nct6775) Use lock function pointers in nct6775_data Denis Pauk
2021-11-28 18:45 ` [PATCH v2 2/3] hwmon: (nct6775) Implement custom lock by ACPI mutex Denis Pauk
2021-11-28 18:45 ` [PATCH v2 3/3] hwmon: (nct6775) add MAXIMUS VII HERO Denis Pauk
2021-12-16 22:22 ` [PATCH v2 0/3] hwmon: (nct6775) Support lock by ACPI mutex Denis Pauk
2021-12-17 16:22   ` Guenter Roeck [this message]
2021-12-17 17:14     ` Eugene Shalygin
2021-12-18 19:17       ` Denis Pauk
  -- strict thread matches above, loose matches on Subject: below --
2021-12-02 15:04 Olli Asikainen
2021-12-02 17:04 ` 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=c6bf6ce9-8b45-e4a2-7167-83bdc8437fca@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 \
    --cc=platform-driver-x86@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox