From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: Lukasz Luba <lukasz.luba@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Zhang Rui <rui.zhang@intel.com>,
netdev@vger.kernel.org, Ido Schimmel <idosch@nvidia.com>,
Petr Machata <petrm@nvidia.com>,
Miri Korenblit <miriam.rachel.korenblit@intel.com>,
linux-wireless@vger.kernel.org, Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
Subject: [PATCH v2 0/9] thermal: Writable trip points handling rework
Date: Mon, 12 Feb 2024 19:25:03 +0100 [thread overview]
Message-ID: <6017196.lOV4Wx5bFT@kreacher> (raw)
Hi Everyone,
This is an update of
https://lore.kernel.org/linux-pm/3232442.5fSG56mABF@kreacher/
fixing a few bugs and renaming the new trip point flags introduced by it.
The original description of the patch series is still applicable:
"The purpose of this patch series is to allow thermal zone creators
to specify which properties (temperature or hysteresis) of which
trip points can be set from user space via sysfs on a per-trip basis
instead of passing writable trips masks to the thermal zone registration
function which is both cumbersome and error prone and it doesn't even
allow to request different treatment of different trip properties.
The writable trip masks used today only affect trip temperatures (that is, if
a trip point is in a writable trips mask, its temperature can be set via
sysfs) and they only take effect if the CONFIG_THERMAL_WRITABLE_TRIPS kernel
configuration option is set, which appears to be assumed by at least some
of the drivers using writable trips masks. Some other drivers using them
simply select CONFIG_THERMAL_WRITABLE_TRIPS which pretty much defeats its
purpose (and imx even sets this option in its defconfig).
For this reasons, patch [1/9] removes CONFIG_THERMAL_WRITABLE_TRIPS and makes
the writable trips masks always work.
Moreover, trip hysteresis, which is not affected either by the writable trips
masks or by CONFIG_THERMAL_WRITABLE_TRIPS, can only be set via sysfs if the
.set_trip_hyst() operation is provided by the given thermal zone, but currently
this thermal zone operation is used by no one, so effectively trip hysteresis
cannot be set via sysfs at all. This is not a problem for the majority of
drivers that want trip temperatures to be set via sysfs, because they also
don't want trip hysteresis to be changed for any trips (at least as far as I
can say), but there are use cases in which it is desirable to be able to
update trip hysteresis as well as trip temperature (for example see
https://lore.kernel.org/linux-pm/20240106191502.29126-1-quic_manafm@quicinc.com/).
Those use cases are not addressed here directly, but after this series
addressing them should be relatively straightforward.
Namely, patch [2/9] adds flags to struct thermal_trip and defines two of them
to indicate whether or not setting the temperature or hysteresis of the given
trip via sysfs is allowed. If a writable trips mask is passed to
thermal_zone_device_register_with_trips(), is it is used to set the
"writable temperature" flag for the trips covered by it and that flag is
then consulted by the thermal sysfs code. The "writable hysteresis" trip
flag is also taken into account by the thermal sysfs code, but it is not set
automatically in any case.
Patch [3/9] is based on the observation that the .set_trip_hyst() thermal zone
operation is never used - it simply drops that callback from struct
thermal_zone_device_ops and adjusts the code checking its presence.
Patches [4-8/9] update drivers using writable trips masks to set the new
"writable temperature" flag directly instead and some of them are simplified
a bit as a result. After these patches, all of the callers of
thermal_zone_device_register_with_trips() pass a zero writable trips mask
to it, so patch [9/9] drops that mask from the functions argument list and
adjusts all of its callers accordingly.
After all of the changes in this series, allowing the hysteresis value to be
set via sysfs for a given trip is a matter of setting its "writable
hysteresis" flag (and analogously for trip temperature)."
Thanks!
next reply other threads:[~2024-02-12 18:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-12 18:25 Rafael J. Wysocki [this message]
2024-02-12 18:26 ` [PATCH v2 1/9] thermal: Get rid of CONFIG_THERMAL_WRITABLE_TRIPS Rafael J. Wysocki
2024-02-22 13:50 ` Daniel Lezcano
2024-02-12 18:31 ` [PATCH v2 2/9] thermal: core: Add flags to struct thermal_trip Rafael J. Wysocki
2024-02-22 14:36 ` Daniel Lezcano
2024-02-22 15:36 ` Daniel Lezcano
2024-02-22 15:51 ` Rafael J. Wysocki
2024-02-22 16:13 ` Rafael J. Wysocki
2024-02-22 19:48 ` [PATCH v2.1 " Rafael J. Wysocki
2024-02-27 11:21 ` Rafael J. Wysocki
2024-02-12 18:32 ` [PATCH v2 3/9] thermal: core: Drop the .set_trip_hyst() thermal zone operation Rafael J. Wysocki
2024-02-22 14:48 ` Daniel Lezcano
2024-02-12 18:34 ` [PATCH v2 4/9] thermal: intel: Set THERMAL_TRIP_FLAG_RW_TEMP directly Rafael J. Wysocki
2024-02-22 15:11 ` Daniel Lezcano
2024-02-12 18:35 ` [PATCH v2 5/9] mlxsw: core_thermal: " Rafael J. Wysocki
2024-02-22 15:13 ` Daniel Lezcano
2024-02-12 18:38 ` [PATCH v2 6/9] wifi: iwlwifi: mvm: " Rafael J. Wysocki
2024-02-15 18:04 ` Rafael J. Wysocki
2024-02-22 15:14 ` Daniel Lezcano
2024-02-12 18:39 ` [PATCH v2 7/9] thermal: imx: " Rafael J. Wysocki
2024-02-22 15:32 ` Daniel Lezcano
2024-02-12 18:40 ` [PATCH v2 8/9] thermal: of: " Rafael J. Wysocki
2024-02-22 13:48 ` Daniel Lezcano
2024-02-22 13:59 ` Rafael J. Wysocki
2024-02-22 15:33 ` Daniel Lezcano
2024-02-12 18:42 ` [PATCH v2 9/9] thermal: core: Eliminate writable trip points masks Rafael J. Wysocki
2024-02-22 15:37 ` Daniel Lezcano
2024-02-15 17:56 ` [PATCH v2 0/9] thermal: Writable trip points handling rework 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=6017196.lOV4Wx5bFT@kreacher \
--to=rjw@rjwysocki.net \
--cc=daniel.lezcano@linaro.org \
--cc=idosch@nvidia.com \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=miriam.rachel.korenblit@intel.com \
--cc=netdev@vger.kernel.org \
--cc=petrm@nvidia.com \
--cc=quic_manafm@quicinc.com \
--cc=rui.zhang@intel.com \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=stanislaw.gruszka@linux.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;
as well as URLs for NNTP newsgroup(s).