linux-kernel - Re: [PATCH v1 00/17] thermal: Rework binding cooling devices to trip points

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]

Message-ID: <CAJZ5v0jo5vh2uD5t4GqBnN0qukMBG_ty33PB=NiEqigqxzBcsw@mail.gmail.com>
Date: Tue, 30 Jul 2024 21:38:40 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Linux PM <linux-pm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Linux ACPI <linux-acpi@...r.kernel.org>, Daniel Lezcano <daniel.lezcano@...aro.org>, 
	Lukasz Luba <lukasz.luba@....com>, Zhang Rui <rui.zhang@...el.com>
Subject: Re: [PATCH v1 00/17] thermal: Rework binding cooling devices to trip points

On Tue, Jul 30, 2024 at 8:18 PM Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>
> Hi Everyone,
>
> The code for binding cooling devices to trip points (and unbinding them from
> trip point) is one of the murkiest pieces of the thermal subsystem.  It is
> convoluted, bloated with unnecessary code doing questionable things, and it
> works backwards.
>
> The idea is to bind cooling devices to trip points in accordance with some
> information known to the thermal zone owner (thermal driver).  This information
> is not known to the thermal core when the thermal zone is registered, so the
> driver needs to be involved, but instead of just asking the driver whether
> or not the given cooling device should be bound to a given trip point, the
> thermal core expects the driver to carry out all of the binding process
> including calling functions specifically provided by the core for this
> purpose which is cumbersome and counter-intuitive.
>
> Because the driver has no information regarding the representation of the trip
> points at the core level, it is forced to walk them (and it has to avoid some
> locking traps while doing this), or it needs to make questionable assumptions
> regarding the ordering of the trips in the core.  There are drivers doing both
> these things.
>
> But there's more.  The size of the binding/unbinding code can be reduced by
> simply moving some parts of it around.  Some checks in it are overkill or
> redundant.  White space is used inconsistently in it.  Its locking can be
> made more straightforward.
>
> Moreover, overhead can be reduced, especially in governors, if the lists of
> thermal instances representing the bindings between cooling devices and trip
> points are moved from thermal zone objects to trip descriptors.
>
> The first 7 patches in the series deal with the minor issues listed above in
> preparation for a more substantial change which is the introduction of a new
> thermal operation, called .should_bind(), that will allow the core to do
> exactly what it needs: as the driver whether or not the given cooling device
> should be bound to a given trip, in patch [08/17].
>
> Patch [09/17] makes the ACPI thermal driver use .should_bind() instead of
> the .bind() and .unbind() operations which is a substantial simplification.
>
> Patch [10/17] unexports two core functions previously used by the ACPI driver
> that can be static now.
>
> Patches [11-14/17] modify the remaining drivers implementing .bind() and
> .undind() to use .should_bind() instead of them which results in significant
> simplifications of the code.
>
> The remaining 3 patches carry out cleanups that can be done after all of the
> previous changes, resulting if further code size reductions.
>
> Thanks!

This is a cover letter for the series at

https://lore.kernel.org/linux-pm/3134863.CbtlEUcBR6@rjwysocki.net/T/#t

but I had made a technical mistake while sending it and it was sent
with an incorrect message ID.  Sorry about that.

Fortunately, Patchwork gets the patch ordering in this series right,
so if you go to

https://patchwork.kernel.org/project/linux-pm/patch/14034461.RDIVbhacDa@rjwysocki.net/

and click on "Series", it will create a mailbox containing all of the
patches in the right order.

Apart from that, I have put this series on the thermal-core-testing
branch in linux-pm.git:

https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=thermal-core-testing

along with the two (unrelated) series posted yesterday:

https://lore.kernel.org/linux-pm/2211925.irdbgypaU6@rjwysocki.net/
https://lore.kernel.org/linux-pm/46571375.fMDQidcC6G@rjwysocki.net/

Thanks!