LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eugene Shalygin <eugene.shalygin@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Denis Pauk <pauk.denis@gmail.com>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	thomas@weissschuh.net, Guenter Roeck <linux@roeck-us.net>,
	Jean Delvare <jdelvare@suse.com>,
	linux-hwmon@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] hwmon: (nct6775) Implement custom lock by ACPI mutex.
Date: Thu, 25 Nov 2021 14:14:51 +0100	[thread overview]
Message-ID: <CAB95QASDiwM+-AwPgGfc7dP=Ctm0s2WP4xrapJzNHJ22B9foAw@mail.gmail.com> (raw)
In-Reply-To: <CAHp75Vfg7LKX-21+b6f5c34G4Y=ZUqrWRbfDt_quCiJe+By-Ww@mail.gmail.com>

Dear Andy, Denis, and Günter,

Denis worked on my code with the first attempt to read EC sensors from
ASUS motherboards and submitted it as a driver named
"asus_wmi_ec_sensors", which is not in hwmon-next. Now he adds the
ACPI lock feature to support other motherboards, and I have another
iteration of the EC sensor driver under development (needs some
polishment) that utilizes the same concept (ACPI lock instead of WMI
methods), which is smaller, cleaner and faster than the WMI-based one.
I'm going to submit it to the mainline too. I think it should replace
the WMI one. In anticipation of that, can we change the name of the
accepted driver (asus_wmi_ec_sensors -> asus_ec_sensors) now, in order
to not confuse users in the next version and to remove implementation
detail from the module name? The drivers provide indistinguishable
data to HWMON.

Regards,
Eugene

On Wed, 24 Nov 2021 at 17:11, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> > +       if (ACPI_FAILURE(acpi_acquire_mutex(data->acpi_wmi_mutex, NULL, ASUSWMI_DELAY_MSEC_LOCK)))
>
>
> On Mon, Nov 22, 2021 at 11:29 PM Denis Pauk <pauk.denis@gmail.com> wrote:
>
> No period in the Subject.
>
> > Use ACPI lock when board has separate lock for monitoring IO.
>
> the board
> a separate
>
> ...
>
> > +#define ASUSWMI_DELAY_MSEC_LOCK                500     /* Wait 0.5 s max. to get the lock */
>
> Units are the last in the names, hence (also check the comment's
> location and English)
>
> /* Wait for up to 0.5 s to acquire the lock */
> #define ASUSWMI_LOCK_TIMEOUT_MS                500
>
> ...
>
> > -       struct mutex update_lock;
> > +       struct mutex update_lock;       /* non ACPI lock */
> > +       acpi_handle acpi_wmi_mutex;     /* ACPI lock */
>
> Couldn't it be an anonymous union?
>
> ...
>
> > +static int nct6775_wmi_lock(struct nct6775_data *data)
> > +{
> > +       if (ACPI_FAILURE(acpi_acquire_mutex(data->acpi_wmi_mutex, NULL, ASUSWMI_DELAY_MSEC_LOCK)))
>
> Please, use a temporary variable here and in the similar cases.
>
>   acpi_status status;
>
>   status = acpi_acquire_mutex(data->acpi_wmi_mutex, NULL,
> ASUSWMI_LOCK_TIMEOUT_MS));
>   if (ACPI_FAILURE(status))
>
> > +               return -EIO;
> > +
> > +       return 0;
> > +}
>
> --
> With Best Regards,
> Andy Shevchenko

  reply	other threads:[~2021-11-25 13:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22 21:28 [PATCH 0/3] hwmon: (nct6775) Support lock by ACPI mutex Denis Pauk
2021-11-22 21:28 ` [PATCH 1/3] hwmon: (nct6775) Use nct6775_*() lock function pointers in nct6775_data Denis Pauk
2021-11-24 16:03   ` Andy Shevchenko
2021-11-25 21:07     ` Denis Pauk
2021-11-25 21:50       ` Andy Shevchenko
2021-11-22 21:28 ` [PATCH 2/3] hwmon: (nct6775) Implement custom lock by ACPI mutex Denis Pauk
2021-11-24 16:10   ` Andy Shevchenko
2021-11-25 13:14     ` Eugene Shalygin [this message]
2021-11-25 13:16       ` Eugene Shalygin
2021-11-25 13:51       ` Guenter Roeck
2021-11-25 13:54         ` Eugene Shalygin
2021-11-25 13:51       ` Andy Shevchenko
2021-11-25 14:00         ` Eugene Shalygin
2021-11-25 19:54           ` Guenter Roeck
2021-11-25 20:05             ` Eugene Shalygin
2021-11-25 20:09               ` Andy Shevchenko
2021-11-25 20:25                 ` Denis Pauk
2021-11-25 20:33                   ` Eugene Shalygin
2021-11-25 21:52                     ` Andy Shevchenko
2021-11-25 20:28                 ` Eugene Shalygin
2021-11-22 21:28 ` [PATCH 3/3] hwmon: (nct6775) add MAXIMUS VII HERO Denis Pauk
2021-11-24 16:21   ` Andy Shevchenko
2021-11-24 16:24     ` Andy Shevchenko

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='CAB95QASDiwM+-AwPgGfc7dP=Ctm0s2WP4xrapJzNHJ22B9foAw@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 \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=thomas@weissschuh.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).