From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com>
Cc: amitk@kernel.org, thara.gopinath@gmail.com, rafael@kernel.org,
rui.zhang@intel.com, lukasz.luba@arm.com,
david.collins@oss.qualcomm.com, srinivas.kandagatla@linaro.org,
stefan.schmidt@linaro.org, quic_tsoni@quicinc.com,
linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, dmitry.baryshkov@linaro.org
Subject: Re: [PATCH v3 3/5 RESEND] thermal: qcom-spmi-temp-alarm: Prepare to support additional Temp Alarm subtypes
Date: Fri, 18 Apr 2025 13:15:50 +0200 [thread overview]
Message-ID: <aAI0Zm5M9ba9ehyI@mai.linaro.org> (raw)
In-Reply-To: <20250320202408.3940777-4-anjelique.melendez@oss.qualcomm.com>
On Thu, Mar 20, 2025 at 01:24:06PM -0700, Anjelique Melendez wrote:
> In preparation to support newer temp alarm subtypes, add the "ops" and
> "configure_trip_temps" references to spmi_temp_alarm_data. This will
> allow for each Temp Alarm subtype to define its own
> thermal_zone_device_ops and properly configure thermal trip temperature.
>
> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com>
> ---
> drivers/thermal/qcom/qcom-spmi-temp-alarm.c | 38 ++++++++++++++-------
> 1 file changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
> index 1cc9369ca9e1..514772e94a28 100644
> --- a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
> +++ b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
> @@ -1,7 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> * Copyright (c) 2011-2015, 2017, 2020, The Linux Foundation. All rights reserved.
> - * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2024-2025, Qualcomm Innovation Center, Inc. All rights reserved.
> */
>
> #include <linux/bitfield.h>
> @@ -71,8 +71,10 @@ static const long temp_map_gen2_v1[THRESH_COUNT][STAGE_COUNT] = {
> struct qpnp_tm_chip;
>
> struct spmi_temp_alarm_data {
> + const struct thermal_zone_device_ops *ops;
> const long (*temp_map)[THRESH_COUNT][STAGE_COUNT];
> int (*get_temp_stage)(struct qpnp_tm_chip *chip);
> + int (*configure_trip_temps)(struct qpnp_tm_chip *chip);
> };
>
> struct qpnp_tm_chip {
> @@ -312,18 +314,39 @@ static irqreturn_t qpnp_tm_isr(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> +static int qpnp_tm_configure_trip_temp(struct qpnp_tm_chip *chip)
> +{
> + int crit_temp, ret;
> +
> + mutex_unlock(&chip->lock);
> +
> + ret = thermal_zone_get_crit_temp(chip->tz_dev, &crit_temp);
> + if (ret)
> + crit_temp = THERMAL_TEMP_INVALID;
> +
> + mutex_lock(&chip->lock);
> +
> + return qpnp_tm_update_critical_trip_temp(chip, crit_temp);
> +}
The qpnp_tm_configure_trip_temp() is called with the lock held which is really
unusual to have this assymetry when dealing with the locks.
In the other side, this code assume it is ok the userspace can change the
critical temperature of the board. Is it really a good idea ?
> static const struct spmi_temp_alarm_data spmi_temp_alarm_data = {
> + .ops = &qpnp_tm_sensor_ops,
> .temp_map = &temp_map_gen1,
> + .configure_trip_temps = qpnp_tm_configure_trip_temp,
> .get_temp_stage = qpnp_tm_gen1_get_temp_stage,
> };
>
> static const struct spmi_temp_alarm_data spmi_temp_alarm_gen2_data = {
> + .ops = &qpnp_tm_sensor_ops,
> .temp_map = &temp_map_gen1,
> + .configure_trip_temps = qpnp_tm_configure_trip_temp,
> .get_temp_stage = qpnp_tm_gen2_get_temp_stage,
> };
>
> static const struct spmi_temp_alarm_data spmi_temp_alarm_gen2_rev1_data = {
> + .ops = &qpnp_tm_sensor_ops,
> .temp_map = &temp_map_gen2_v1,
> + .configure_trip_temps = qpnp_tm_configure_trip_temp,
> .get_temp_stage = qpnp_tm_gen2_get_temp_stage,
> };
>
> @@ -336,7 +359,6 @@ static int qpnp_tm_init(struct qpnp_tm_chip *chip)
> {
> int ret;
> u8 reg = 0;
> - int crit_temp;
>
> mutex_lock(&chip->lock);
>
> @@ -355,15 +377,7 @@ static int qpnp_tm_init(struct qpnp_tm_chip *chip)
> if (chip->stage)
> chip->temp = qpnp_tm_decode_temp(chip, chip->stage);
>
> - mutex_unlock(&chip->lock);
> -
> - ret = thermal_zone_get_crit_temp(chip->tz_dev, &crit_temp);
> - if (ret)
> - crit_temp = THERMAL_TEMP_INVALID;
> -
> - mutex_lock(&chip->lock);
> -
> - ret = qpnp_tm_update_critical_trip_temp(chip, crit_temp);
> + ret = chip->data->configure_trip_temps(chip);
> if (ret < 0)
> goto out;
>
> @@ -483,7 +497,7 @@ static int qpnp_tm_probe(struct platform_device *pdev)
> * before the hardware initialization is completed.
> */
> chip->tz_dev = devm_thermal_of_zone_register(
> - &pdev->dev, 0, chip, &qpnp_tm_sensor_ops);
> + &pdev->dev, 0, chip, chip->data->ops);
> if (IS_ERR(chip->tz_dev))
> return dev_err_probe(&pdev->dev, PTR_ERR(chip->tz_dev),
> "failed to register sensor\n");
> --
> 2.34.1
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2025-04-18 11:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 20:24 [PATCH v3 0/5 RESEND] thermal: qcom-spmi-temp-alarm: Add support for new TEMP_ALARM subtypes Anjelique Melendez
2025-03-20 20:24 ` [PATCH v3 1/5 RESEND] thermal: qcom-spmi-temp-alarm: enable stage 2 shutdown when required Anjelique Melendez
2025-04-10 21:01 ` Dmitry Baryshkov
2025-04-18 10:54 ` Daniel Lezcano
2025-03-20 20:24 ` [PATCH v3 2/5 RESEND] thermal: qcom-spmi-temp-alarm: Add temp alarm data struct based on HW subtype Anjelique Melendez
2025-03-20 20:24 ` [PATCH v3 3/5 RESEND] thermal: qcom-spmi-temp-alarm: Prepare to support additional Temp Alarm subtypes Anjelique Melendez
2025-04-10 21:01 ` Dmitry Baryshkov
2025-04-18 11:15 ` Daniel Lezcano [this message]
2025-04-23 23:20 ` Anjelique Melendez
2025-03-20 20:24 ` [PATCH v3 4/5 RESEND] thermal: qcom-spmi-temp-alarm: add support for GEN2 rev 2 PMIC peripherals Anjelique Melendez
2025-04-10 21:03 ` Dmitry Baryshkov
2025-04-18 11:19 ` Daniel Lezcano
2025-04-23 23:31 ` Anjelique Melendez
2025-04-30 16:38 ` Daniel Lezcano
2025-03-20 20:24 ` [PATCH v3 5/5 RESEND] thermal: qcom-spmi-temp-alarm: add support for LITE " Anjelique Melendez
2025-04-10 21:04 ` Dmitry Baryshkov
2025-04-08 21:51 ` [PATCH v3 0/5 RESEND] thermal: qcom-spmi-temp-alarm: Add support for new TEMP_ALARM subtypes Anjelique Melendez
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=aAI0Zm5M9ba9ehyI@mai.linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=amitk@kernel.org \
--cc=anjelique.melendez@oss.qualcomm.com \
--cc=david.collins@oss.qualcomm.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=quic_tsoni@quicinc.com \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=stefan.schmidt@linaro.org \
--cc=thara.gopinath@gmail.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