[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ff51089b-e07d-4aa3-91f3-a6018baf8ec2@arm.com>
Date: Fri, 25 Oct 2024 14:53:03 +0100
From: Lukasz Luba <lukasz.luba@....com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
LKML <linux-kernel@...r.kernel.org>, Linux PM <linux-pm@...r.kernel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>, Zhang Rui <rui.zhang@...el.com>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Subject: Re: [PATCH v2 01/11] thermal: core: Add and use thermal zone guard
On 10/23/24 10:50, Rafael J. Wysocki wrote:
> Hi Lukasz,
>
> On Tue, Oct 22, 2024 at 11:01 PM Lukasz Luba <lukasz.luba@....com> wrote:
>>
>> Hi Rafael,
>>
>> On 10/10/24 23:05, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>>>
>>> Add and use a guard for thermal zone locking.
>>>
>>> This allows quite a few error code paths to be simplified among
>>> other things and brings in a noticeable code size reduction for
>>> a good measure.
>>>
>>> No intentional functional impact.
>>>
>>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>>> ---
>>>
>>> This is a new iteration of
>>>
>>> https://lore.kernel.org/linux-pm/3241904.5fSG56mABF@rjwysocki.net/
>>>
>>> that has been combined with
>>>
>>> https://lore.kernel.org/linux-pm/4613601.LvFx2qVVIh@rjwysocki.net/
>>>
>>> and rebased on top of
>>>
>>> https://lore.kernel.org/linux-pm/12549318.O9o76ZdvQC@rjwysocki.net/
>>>
>>> and
>>>
>>> https://lore.kernel.org/linux-pm/2215082.irdbgypaU6@rjwysocki.net/
>>>
>>> ---
>>> drivers/thermal/thermal_core.c | 61 +++++++---------------------
>>> drivers/thermal/thermal_core.h | 4 +
>>> drivers/thermal/thermal_debugfs.c | 25 +++++++----
>>> drivers/thermal/thermal_helpers.c | 17 ++-----
>>> drivers/thermal/thermal_hwmon.c | 5 --
>>> drivers/thermal/thermal_netlink.c | 21 ++-------
>>> drivers/thermal/thermal_sysfs.c | 81 ++++++++++++++++----------------------
>>> drivers/thermal/thermal_trip.c | 8 ---
>>> 8 files changed, 86 insertions(+), 136 deletions(-)
>>>
>>
>>
>> [snip]
>>
>> Surprise, how the code can look smaller using that
>> style with 'guard'.
>
> Yes, it gets more concise.
>
> Not only that, though. It is also less error-prone, because you won't
> forget to unlock the lock in an error path and you won't use "lock"
> instead of "unlock" by mistake etc.
>
> Moreover, it kind of promotes dividing the code into smaller
> self-contained pieces, which is a plus too IMV.
I cannot agree more!
Powered by blists - more mailing lists