linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Denis Pauk <pauk.denis@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Eugene Shalygin <eugene.shalygin@gmail.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	thomas@weissschuh.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 22:25:26 +0200	[thread overview]
Message-ID: <20211125222526.405ce775@netbook-debian> (raw)
In-Reply-To: <CAHp75Vdi8ujoC5LTYqNmiWe1dTxrYRQKS+YtZE921d-6CZTs=A@mail.gmail.com>

Hi,

On Thu, 25 Nov 2021 22:09:46 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Thu, Nov 25, 2021 at 10:05 PM Eugene Shalygin
> <eugene.shalygin@gmail.com> wrote:
> >
> > On Thu, 25 Nov 2021 at 20:54, Guenter Roeck <linux@roeck-us.net>
> > wrote:  
> > > We won't be heving two drivers with the same functionality. Give
> > > me one reason why I should not drop the wmi driver (or both of
> > > them; I am not sure which one we are talking about here).
> > >
> > > On top of all that, this submission isn't about any of the wmi
> > > drivers, but for the nct6775 driver, which just adds to the
> > > confusion.  
> >
> > Let me try to explain once again, please. I began to dig into the
> > ASUS sensors and how to read their values and at first found the WMI
> > function to do that, wrote a driver and Denis submitted it as
> > asus_wmi_ec_sensors. Now, I know a better and simpler way to read
> > those sensors, which uses ACPI mutex directly. I suggested Denis to
> > use the mutex way for the nct6775 driver for motherboards without
> > WMI functions to read from the nct chip. With that change entering
> > the nct driver, I want to submit my updated driver for EC sensors,
> > replacing the asus_wmi_ec_sensors code (which is essentially my old
> > driver).
> >
> > So, now I ask to rename asus_wmi_sensors to asus_ec_sensors (source
> > file and KBuild options) already before 5.16 is released, because
> > the updated code, which I will submit later, and which will replace
> > that in asus_wmi_ec_sensors.c, does not use WMI.
> >
> > Hope this clarifies my request and intention.  
> 
> Since you are talking about something which is not ready yet (as I
> read "will" above), I propose a compromise variant, i.e. let's leave
> current driver(s) as is for v5.17 and after v5.17-rc1 you submit your
> proposal for review. Okay?
> 

I would like to propose to leave the current name of the driver and add
the same logic as in the current patch. So when we know the exact name
of acpi mutex - code will use such mutex for lock and directly read EC
memory region. In case if we don't know the exact mutex name/path or for
some reason ASUS decides to change UEFI code - code will use WMI
methods. In such a case, adding or checking a new motherboard will
require only adding a minimal list of well known registers without
disassembling UEFI code.   

What do you think?

Best regards,
             Denis.

  reply	other threads:[~2021-11-25 20:30 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
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 [this message]
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=20211125222526.405ce775@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 \
    --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).