All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	srinivas.pandruvada@linux.intel.com, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org, rui.zhang@intel.com,
	Amit Kucheria <amitk@kernel.org>
Subject: Re: [PATCH 1/3] thermal/drivers/intel: Use generic trip points for quark_dts
Date: Tue, 31 Jan 2023 20:11:05 +0100	[thread overview]
Message-ID: <CAJZ5v0iOYH4WR5WoH=jL6VWKhB4CMeZv5V3U0Q_c_qdCJvvvBw@mail.gmail.com> (raw)
In-Reply-To: <621aca19-6a44-9d42-6fde-1835035c28b4@linaro.org>

On Tue, Jan 31, 2023 at 5:41 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 26/01/2023 15:15, Rafael J. Wysocki wrote:
> > On Wed, Jan 18, 2023 at 7:16 PM Daniel Lezcano
> > <daniel.lezcano@linaro.org> wrote:
> >>
> >> The thermal framework gives the possibility to register the trip
> >> points with the thermal zone. When that is done, no get_trip_* ops are
> >> needed and they can be removed.
> >>
> >> Convert ops content logic into generic trip points and register them with the
> >> thermal zone.
> >>
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >> ---
>
> [ ... ]
>
> >> -       aux_entry->tzone = thermal_zone_device_register("quark_dts",
> >> -                       QRK_MAX_DTS_TRIPS,
> >> -                       wr_mask,
> >> -                       aux_entry, &tzone_ops, NULL, 0, polling_delay);
> >> +       err = get_trip_temp(QRK_DTS_ID_TP_CRITICAL, &temperature);
> >> +       if (err)
> >> +               goto err_ret;
> >> +
> >> +       aux_entry->trips[QRK_DTS_ID_TP_CRITICAL].temperature = temperature;
> >> +       aux_entry->trips[QRK_DTS_ID_TP_CRITICAL].type = THERMAL_TRIP_CRITICAL;
> >> +
> >> +       err = get_trip_temp(QRK_DTS_ID_TP_HOT, &temperature);
> >> +       if (err)
> >> +               goto err_ret;
> >
> > If I'm not mistaken, this won't even try to register the thermal zone
> > if at least one trip cannot be initialized, but previously it was
> > registered in that case, but the trips that failed to respond were
> > disabled.
> >
> > This is a change in behavior that would at least need to be documented
> > in the changelog, but it isn't.
> >
> > I'm not sure if it is safe to make even, however.
>
> Thanks for catching this.
>
> Two solutions:
>
> 1. Set the temperature to THERMAL_TEMP_INVALID and change
> get_thermal_trip() to return -EINVAL or -ERANGE if the temperature is
> THERMAL_TEMP_INVALID
>
> 2. Register only the valid trip points.
>
> What would be the preferable way ?

I think that the trip points that are registered currently need to
still be registered after the change.

Does registering a trip point with the temperature set to
THERMAL_TEMP_INVALID cause it to be effectively disabled?

  reply	other threads:[~2023-01-31 19:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18 18:16 [PATCH 1/3] thermal/drivers/intel: Use generic trip points for quark_dts Daniel Lezcano
2023-01-18 18:16 ` [PATCH 2/3] thermal/drivers/intel: Use generic trip points for processor_thermal_device_pci Daniel Lezcano
2023-01-18 19:09   ` srinivas pandruvada
2023-01-23 18:02     ` Daniel Lezcano
2023-01-23 19:31       ` srinivas pandruvada
2023-01-26 15:18   ` Rafael J. Wysocki
2023-01-18 18:16 ` [PATCH 3/3] thermal/drivers/intel: Use generic trip points for intel_soc_dts_iosf Daniel Lezcano
2023-01-19 20:04   ` Rafael J. Wysocki
2023-01-23 18:09     ` Daniel Lezcano
2023-01-23 20:19       ` Rafael J. Wysocki
2023-01-24 10:28         ` Daniel Lezcano
2023-01-24 14:09           ` Rafael J. Wysocki
2023-01-26 16:47   ` Rafael J. Wysocki
2023-01-31 17:03     ` Daniel Lezcano
2023-01-31 19:17       ` Rafael J. Wysocki
2023-02-02 14:36         ` Daniel Lezcano
2023-02-02 14:43           ` Rafael J. Wysocki
2023-02-02 15:54             ` Daniel Lezcano
2023-01-26 14:15 ` [PATCH 1/3] thermal/drivers/intel: Use generic trip points for quark_dts Rafael J. Wysocki
2023-01-31 16:41   ` Daniel Lezcano
2023-01-31 19:11     ` Rafael J. Wysocki [this message]
2023-01-31 23:55       ` Daniel Lezcano
2023-02-01 10:42       ` Daniel Lezcano
2023-02-01 18:47         ` Rafael J. Wysocki
2023-02-01 19:27           ` Daniel Lezcano
2023-02-02 10:32             ` Rafael J. Wysocki
2023-02-02 13:31               ` 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='CAJZ5v0iOYH4WR5WoH=jL6VWKhB4CMeZv5V3U0Q_c_qdCJvvvBw@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=amitk@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.