From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Lukasz Luba <lukasz.luba@arm.com>,
Zhang Rui <rui.zhang@intel.com>
Subject: [RFC PATCH for 6.13 v1 04/20] thermal: core: Mark thermal zones as initializing to start with
Date: Sat, 14 Sep 2024 12:30:27 +0200 [thread overview]
Message-ID: <2973309.e9J7NaK4W3@rjwysocki.net> (raw)
In-Reply-To: <6100907.lOV4Wx5bFT@rjwysocki.net>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After thermal_zone_device_register_with_trips() has called
device_register() and it has registered the new thermal zone device
with the driver core, user space may access its sysfs attributes and,
among other things, it may enable the thermal zone before it is ready.
To address this, introduce a new thermal zone state flag for
initialization and set it before calling device_register() in
thermal_zone_device_register_with_trips(). This causes
__thermal_zone_device_update() to return early until the new flag
is cleared.
To clear it when the thermal zone is ready, introduce a new
function called thermal_zone_init_complete() that will also invoke
__thermal_zone_device_update() after clearing that flag (both under the
thernal zone lock) and make thermal_zone_device_register_with_trips()
call the new function instead of checking need_update and calling
thermal_zone_device_update() when it is set.
After this change, if user space enables the thermal zone prematurely,
__thermal_zone_device_update() will return early for it until
thermal_zone_init_complete() is called. In turn, if the thermal zone
is not enabled by user space before thermal_zone_init_complete() is
called, the __thermal_zone_device_update() call in it will return early
because the thermal zone has not been enabled yet, but that function
will be invoked again by thermal_zone_device_set_mode() when the thermal
zone is enabled and it will not return early this time.
The checking of need_update is not necessary any more because the
__thermal_zone_device_update() calls potentially triggered by cooling
device binding take place before calling thermal_zone_init_complete(),
so they all will return early, which means that
thermal_zone_init_complete() must call __thermal_zone_device_update()
in case the thermal zone is enabled prematurely by user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/thermal/thermal_core.c | 14 +++++++++++---
drivers/thermal/thermal_core.h | 1 +
2 files changed, 12 insertions(+), 3 deletions(-)
Index: linux-pm/drivers/thermal/thermal_core.c
===================================================================
--- linux-pm.orig/drivers/thermal/thermal_core.c
+++ linux-pm/drivers/thermal/thermal_core.c
@@ -1318,6 +1318,14 @@ static void thermal_zone_add_to_list(str
list_add_tail(&tz->node, &thermal_tz_list);
}
+static void thermal_zone_init_complete(struct thermal_zone_device *tz)
+{
+ guard(thermal_zone)(tz);
+
+ tz->state &= ~TZ_STATE_FLAG_INIT;
+ __thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
+}
+
/**
* thermal_zone_device_register_with_trips() - register a new thermal zone device
* @type: the thermal zone device type
@@ -1435,6 +1443,8 @@ thermal_zone_device_register_with_trips(
tz->passive_delay_jiffies = msecs_to_jiffies(passive_delay);
tz->recheck_delay_jiffies = THERMAL_RECHECK_DELAY;
+ tz->state = TZ_STATE_FLAG_INIT;
+
/* sys I/F */
/* Add nodes that are always present via .groups */
result = thermal_zone_create_device_groups(tz);
@@ -1486,9 +1496,7 @@ thermal_zone_device_register_with_trips(
mutex_unlock(&thermal_list_lock);
- /* Update the new thermal zone and mark it as already updated. */
- if (atomic_cmpxchg(&tz->need_update, 1, 0))
- thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
+ thermal_zone_init_complete(tz);
thermal_notify_tz_create(tz);
Index: linux-pm/drivers/thermal/thermal_core.h
===================================================================
--- linux-pm.orig/drivers/thermal/thermal_core.h
+++ linux-pm/drivers/thermal/thermal_core.h
@@ -64,6 +64,7 @@ struct thermal_governor {
#define TZ_STATE_FLAG_SUSPENDED BIT(0)
#define TZ_STATE_FLAG_RESUMING BIT(1)
+#define TZ_STATE_FLAG_INIT BIT(2)
#define TZ_STATE_READY 0
next prev parent reply other threads:[~2024-09-14 11:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-14 10:24 [RFC PATCH for 6.13 v1 00/20] thermal: core: Updates related to thermal zone initialization, suspend and locking Rafael J. Wysocki
2024-09-14 10:25 ` [RFC PATCH for 6.13 v1 01/20] thermal: core: Use the thermal zone guard in more cases Rafael J. Wysocki
2024-09-14 10:27 ` [RFC PATCH for 6.13 v1 02/20] thermal: core: Rearrange PM notification code Rafael J. Wysocki
2024-09-14 10:28 ` [RFC PATCH for 6.13 v1 03/20] thermal: core: Represent suspend-related thermal zone flags as bits Rafael J. Wysocki
2024-09-14 10:30 ` Rafael J. Wysocki [this message]
2024-09-14 10:31 ` [RFC PATCH for 6.13 v1 05/20] thermal: core: Fix race between zone registration and system suspend Rafael J. Wysocki
2024-09-14 10:32 ` [RFC PATCH for 6.13 v1 06/20] thermal: core: Consolidate thermal zone locking during initialization Rafael J. Wysocki
2024-09-14 10:34 ` [RFC PATCH for 6.13 v1 07/20] thermal: core: Mark thermal zones as exiting before unregistration Rafael J. Wysocki
2024-09-14 10:35 ` [RFC PATCH for 6.13 v1 08/20] thermal: core: Consolidate thermal zone locking in the exit path Rafael J. Wysocki
2024-09-14 10:36 ` [RFC PATCH for 6.13 v1 09/20] thermal: core: Update thermal zones after cooling device binding Rafael J. Wysocki
2024-09-14 10:37 ` [RFC PATCH for 6.13 v1 10/20] thermal: core: Drop need_update field from struct thermal_zone_device Rafael J. Wysocki
2024-09-14 10:38 ` [RFC PATCH for 6.13 v1 11/20] thermal: core: Separate code running under thermal_list_lock Rafael J. Wysocki
2024-09-14 10:40 ` [RFC PATCH for 6.13 v1 12/20] thermal: core: Manage thermal_list_lock using a mutex guard Rafael J. Wysocki
2024-09-14 10:41 ` [RFC PATCH for 6.13 v1 13/20] thermal: core: Call thermal_governor_update_tz() outside of cdev lock Rafael J. Wysocki
2024-09-14 10:43 ` [RFC PATCH for 6.13 v1 14/20] thermal: core: Introduce thermal_instance_add() Rafael J. Wysocki
2024-09-14 10:44 ` [RFC PATCH for 6.13 v1 15/20] thermal: core: Introduce thermal_instance_delete() Rafael J. Wysocki
2024-09-14 10:45 ` [RFC PATCH for 6.13 v1 16/20] thermal: core: Introduce thermal_cdev_update_nocheck() Rafael J. Wysocki
2024-09-14 10:47 ` [RFC PATCH for 6.13 v1 17/20] thermal: core: Add and use cooling device guard Rafael J. Wysocki
2024-09-14 10:48 ` [RFC PATCH for 6.13 v1 18/20] thermal: core: Call __thermal_cdev_update() on cdev unbind Rafael J. Wysocki
2024-09-14 10:49 ` [RFC PATCH for 6.13 v1 19/20] thermal: core: Separate thermal zone governor initialization Rafael J. Wysocki
2024-09-14 10:50 ` [RFC PATCH for 6.13 v1 20/20] thermal: core: Manage thermal_governor_lock using a mutex guard Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2973309.e9J7NaK4W3@rjwysocki.net \
--to=rjw@rjwysocki.net \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=rui.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®