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]
Message-ID: <CAB95QATUTvoopfCUez3exhStcGtPGacpyAYW-rswGnVSw-cmjw@mail.gmail.com>
Date:   Fri, 17 Dec 2021 23:33:24 +0100
From:   Eugene Shalygin <eugene.shalygin@...il.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Denis Pauk <pauk.denis@...il.com>,
        Jean Delvare <jdelvare@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-hwmon@...r.kernel.org
Subject: Re: [PATCH 1/3] hwmon: (asus-ec-sensors) add driver for ASUS EC

Günter,

On Fri, 17 Dec 2021 at 22:52, Guenter Roeck <linux@...ck-us.net> wrote:
> There is a lot of complexity around mutex_path in this driver, yet there is
> always exactly one entry for each board, and the name of the mutex is always
> the same for all boards. This doesn't make sense. Either the code is needed
> or it isn't. We don't usually add complex code like this into the kernel
> "just because it may be needed at some point in the future". Either give me
> a use case, or drop it all.

When we discussed this approach which utilises an ACPI mutex, Andy and
Denis were sceptical about its maintainability. One of the objections
was that the mutex name is internal to the DSDT code and can be
changed by ASUS. I know when older AM4 boards received BIOS updates
for Ryzen 5000, their BIOS changed completely and I overheard that the
DSDT code changed too. Unfortunately, I have no samples at hand. So I
went ahead and added version support. I can, of course, revert that
and apply it if somebody encounters such a BIOS update. To some extent
I wanted to demonstrate how overcoming the problem with possible
changes of the mutex path can look.

Best regards,
Eugene

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ