linux-kernel - Re: [PATCH 2/3] hwmon: (nct6775) Implement custom lock by ACPI mutex.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Nov 2021 22:25:26 +0200
From:   Denis Pauk <pauk.denis@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Eugene Shalygin <eugene.shalygin@...il.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        thomas@...ssschuh.net, Jean Delvare <jdelvare@...e.com>,
        linux-hwmon@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] hwmon: (nct6775) Implement custom lock by ACPI
 mutex.

Hi,

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

> On Thu, Nov 25, 2021 at 10:05 PM Eugene Shalygin
> <eugene.shalygin@...il.com> wrote:
> >
> > On Thu, 25 Nov 2021 at 20:54, Guenter Roeck <linux@...ck-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.