linux-kernel - Re: [PATCH 1/3] hwmon: (asus-ec-sensors) add driver for ASUS EC

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] [day] [month] [year] [list]

Date:   Fri, 17 Dec 2021 15:47:43 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Eugene Shalygin <eugene.shalygin@...il.com>
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

On 12/17/21 2:33 PM, Eugene Shalygin wrote:
> 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.
> 

That is not how kernel development works. It does not make sense to
introduce code that isn't used. The code is by its nature untested,
and it is completely unknown if it is even going to work if it is ever
needed. We simply can not predict how a future BIOS version / DSDT
looks like.

I don't have an answer for the maintainability problem, but introducing
speculative code is most definitely not the answer.

Guenter