linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Lukasz Luba <lukasz.luba@arm.com>, rui.zhang@intel.com
Cc: kai.heng.feng@canonical.com, srinivas.pandruvada@linux.intel.com,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Amit Kucheria <amitk@kernel.org>
Subject: Re: [PATCH 2/5] thermal/core: Add critical and hot ops
Date: Thu, 10 Dec 2020 14:37:27 +0100	[thread overview]
Message-ID: <565c354e-0850-47f3-ad58-ee28fdedcfb2@linaro.org> (raw)
In-Reply-To: <fd9b262a-cb9a-bd88-5790-0ca5f9a7bdad@arm.com>

On 10/12/2020 13:44, Lukasz Luba wrote:
> 
> 
> On 12/10/20 12:15 PM, Daniel Lezcano wrote:
>> Currently there is no way to the sensors to directly call an ops in
>> interrupt mode without calling thermal_zone_device_update assuming all
>> the trip points are defined.
>>
>> A sensor may want to do something special if a trip point is hot or
>> critical.
>>
>> This patch adds the critical and hot ops to the thermal zone device,
>> so a sensor can directly invoke them or let the thermal framework to
>> call the sensor specific ones.
>>
>> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> ---
>>   drivers/thermal/thermal_core.c | 43 +++++++++++++++++++++-------------
>>   include/linux/thermal.h        |  3 +++
>>   2 files changed, 30 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/thermal/thermal_core.c
>> b/drivers/thermal/thermal_core.c
>> index e6771e5aeedb..cee0b31b5cd7 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -375,6 +375,25 @@ static void thermal_emergency_poweroff(void)
>>                     msecs_to_jiffies(poweroff_delay_ms));
>>   }
>>   +void thermal_zone_device_critical(struct thermal_zone_device *tz)
>> +{
>> +    dev_emerg(&tz->device, "%s: critical temperature reached, "
>> +          "shutting down\n", tz->type);
>> +
>> +    mutex_lock(&poweroff_lock);
>> +    if (!power_off_triggered) {
>> +        /*
>> +         * Queue a backup emergency shutdown in the event of
>> +         * orderly_poweroff failure
>> +         */
>> +        thermal_emergency_poweroff();
>> +        orderly_poweroff(true);
>> +        power_off_triggered = true;
>> +    }
>> +    mutex_unlock(&poweroff_lock);
>> +}
>> +EXPORT_SYMBOL(thermal_zone_device_critical);
>> +
>>   static void handle_critical_trips(struct thermal_zone_device *tz,
>>                     int trip, enum thermal_trip_type trip_type)
>>   {
>> @@ -391,22 +410,10 @@ static void handle_critical_trips(struct
>> thermal_zone_device *tz,
>>       if (tz->ops->notify)
>>           tz->ops->notify(tz, trip, trip_type);
>>   -    if (trip_type == THERMAL_TRIP_CRITICAL) {
>> -        dev_emerg(&tz->device,
>> -              "critical temperature reached (%d C), shutting down\n",
>> -              tz->temperature / 1000);
>> -        mutex_lock(&poweroff_lock);
>> -        if (!power_off_triggered) {
>> -            /*
>> -             * Queue a backup emergency shutdown in the event of
>> -             * orderly_poweroff failure
>> -             */
>> -            thermal_emergency_poweroff();
>> -            orderly_poweroff(true);
>> -            power_off_triggered = true;
>> -        }
>> -        mutex_unlock(&poweroff_lock);
>> -    }
>> +    if (trip_type == THERMAL_TRIP_HOT && tz->ops->hot)
>> +        tz->ops->hot(tz);
>> +    else if (trip_type == THERMAL_TRIP_CRITICAL)
>> +        tz->ops->critical(tz);
> 
> I can see that in the patch 3/5 there driver .critical() callback
> calls framework thermal_zone_device_critical() at the end.
> I wonder if we could always call this framework function.

It is actually done on purpose, we want to let the driver to handle the
critical routine which may not end up with an emergency shutdown.

[ ... ]

>>   #else
>>   static inline struct thermal_zone_device *thermal_zone_device_register(
>>       const char *type, int trips, int mask, void *devdata,
>>
> 
> I am just concerned about drivers which provide own .critical() callback
> but forgot to call thermal_zone_device_critical() at the end and
> framework could skip it.
> 
> Or we can make sure during the review that it's not an issue (and ignore
> out of tree drivers)?

Yes, the framework guarantees if the critical trip point is crossed we
call the emergency shutdown by default. If the driver choose to override
it, it takes responsibility of the change.



-- 
<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

  reply	other threads:[~2020-12-10 13:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 12:15 [PATCH 1/5] thermal/core: Emit a warning if the thermal zone is updated without ops Daniel Lezcano
2020-12-10 12:15 ` [PATCH 2/5] thermal/core: Add critical and hot ops Daniel Lezcano
2020-12-10 12:44   ` Lukasz Luba
2020-12-10 13:37     ` Daniel Lezcano [this message]
2020-12-10 13:51       ` Lukasz Luba
2020-12-10 12:15 ` [PATCH 3/5] thermal/drivers/acpi: Use hot and critical ops Daniel Lezcano
2020-12-17  6:28   ` Daniel Lezcano
2020-12-17 11:38     ` Srinivas Pandruvada
2020-12-17 13:10       ` Daniel Lezcano
2020-12-10 12:15 ` [PATCH 4/5] thermal/drivers/rcar: Remove notification usage Daniel Lezcano
2020-12-10 16:10   ` Niklas Söderlund
2020-12-10 12:15 ` [PATCH 5/5] thermal/core: Remove notify ops Daniel Lezcano
2020-12-10 14:37   ` Lukasz Luba
2020-12-14 14:40 ` [thermal: thermal/next] thermal/core: Emit a warning if the thermal zone is updated without ops thermal-bot for Daniel Lezcano

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=565c354e-0850-47f3-ad58-ee28fdedcfb2@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=amitk@kernel.org \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=rui.zhang@intel.com \
    --cc=srinivas.pandruvada@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).