From: "Thomas Weißschuh" <thomas@weissschuh.net>
To: Sung-Chi <lschyi@chromium.org>
Cc: Lee Jones <lee@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Benson Leung <bleung@chromium.org>,
Guenter Roeck <groeck@chromium.org>,
Jean Delvare <jdelvare@suse.com>,
devicetree@vger.kernel.org, chrome-platform@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v2] hwmon: (cros_ec) register thermal sensors to thermal framework
Date: Mon, 11 Nov 2024 17:30:51 +0100 [thread overview]
Message-ID: <a469852b-4cbd-467c-89de-b1acf6de1402@t-8ch.de> (raw)
In-Reply-To: <20241111095045.1218986-1-lschyi@chromium.org>
On 2024-11-11 17:50:30+0800, Sung-Chi wrote:
> From: "Sung-Chi, Li" <lschyi@chromium.org>
>
> cros_ec hwmon driver probes available thermal sensors when probing the
> driver. Register these thermal sensors to the thermal framework, such
> that thermal framework can adopt these sensors as well.
The driver also supports fan readings. These could also be wired up as
cooling devices.
> To make cros_ec registrable to thermal framework, the cros_ec dts need
> the corresponding changes:
>
> &cros_ec {
> #thermal-sensor-cells = <1>;
> };
If this is the only thing that is meant to be configured I'm wondering
why the OF variant is needed in the first place.
Why not register a non-OF thermal device?
Please send the next revision also to the maintainers of the THERMAL
subsystem so we can figure out the most correct way forward.
> Change-Id: I29b638427c715cb44391496881fc61ad53abccaf
> Signed-off-by: Sung-Chi, Li <lschyi@chromium.org>
> ---
> Changes in v2:
> - Rename `cros_ec_sensor_data` to `cros_ec_hwmon_thermal_zone_data`.
> - Rename `addr` in struct `cros_ec_hwmon_thermal_zone_data` to `idx`.
> - Use `cros_ec_hwmon_temp_to_millicelsius` to do value conversion in
> `cros_ec_thermal_get_temp` function.
> - Rename `cros_ec_thermal_get_temp` to `cros_ec_hwmon_thermal_get_temp` to
> make `cros_ec_hwmon` a prefix.
> - Use `%pe` in `cros_ec_hwmon_probe_temp_sensors` when printing out
> `data->tz_dev` if failed register thermal device.
> - Remove `cros_ec_hwmon_remove`, and the `.remove` value in
> `cros_ec_hwmon_driver` since there is no need to call
> `devm_thermal_of_zone_unregister` for clean up.
> - Revert function signature of `cros_ec_hwmon_probe_temp_sensors` since all
> needed parameters are presented.
> - Revert include of `linux/list.h` because no list data structure is used.
> ---
> drivers/hwmon/cros_ec_hwmon.c | 41 +++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/drivers/hwmon/cros_ec_hwmon.c b/drivers/hwmon/cros_ec_hwmon.c
> index 5514cf780b8b..81e563e0455f 100644
> --- a/drivers/hwmon/cros_ec_hwmon.c
> +++ b/drivers/hwmon/cros_ec_hwmon.c
> @@ -12,6 +12,7 @@
> #include <linux/platform_device.h>
> #include <linux/platform_data/cros_ec_commands.h>
> #include <linux/platform_data/cros_ec_proto.h>
> +#include <linux/thermal.h>
> #include <linux/types.h>
> #include <linux/units.h>
>
> @@ -23,6 +24,12 @@ struct cros_ec_hwmon_priv {
> u8 usable_fans;
> };
>
> +struct cros_ec_hwmon_thermal_zone_data {
> + struct cros_ec_device *cros_ec;
> + struct thermal_zone_device *tz_dev;
> + int idx;
> +};
> +
> static int cros_ec_hwmon_read_fan_speed(struct cros_ec_device *cros_ec, u8 index, u16 *speed)
> {
> int ret;
> @@ -185,11 +192,30 @@ static const struct hwmon_chip_info cros_ec_hwmon_chip_info = {
> .info = cros_ec_hwmon_info,
> };
>
> +static int cros_ec_hwmon_thermal_get_temp(struct thermal_zone_device *tz, int *temp)
> +{
> + struct cros_ec_hwmon_thermal_zone_data *data =
> + thermal_zone_device_priv(tz);
> + int ret;
> + u8 val;
> +
> + ret = cros_ec_hwmon_read_temp(data->cros_ec, data->idx, &val);
> + if (ret || cros_ec_hwmon_is_error_temp(temp))
> + return -ENODATA;
> + *temp = cros_ec_hwmon_temp_to_millicelsius(val);
> + return 0;
> +}
> +
> +static const struct thermal_zone_device_ops thermal_ops = {
Symbol still needs namespacing.
> + .get_temp = cros_ec_hwmon_thermal_get_temp,
> +};
> +
> static void cros_ec_hwmon_probe_temp_sensors(struct device *dev, struct cros_ec_hwmon_priv *priv,
> u8 thermal_version)
> {
> struct ec_params_temp_sensor_get_info req = {};
> struct ec_response_temp_sensor_get_info resp;
> + struct cros_ec_hwmon_thermal_zone_data *data;
> size_t candidates, i, sensor_name_size;
> int ret;
> u8 temp;
> @@ -216,6 +242,21 @@ static void cros_ec_hwmon_probe_temp_sensors(struct device *dev, struct cros_ec_
> priv->temp_sensor_names[i] = devm_kasprintf(dev, GFP_KERNEL, "%.*s",
> (int)sensor_name_size,
> resp.sensor_name);
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + continue;
> +
> + data->idx = i;
> + data->cros_ec = priv->cros_ec;
> + data->tz_dev = devm_thermal_of_zone_register(
> + priv->cros_ec->dev, i, data, &thermal_ops);
Doesn't this also automatically create new hwmon device off of the
thermal device? That shouldn't happen.
In general I'm not sure how the hwmon and thermal subsystems are meant
to interact. Is one recommended over the other?
Should the driver become a first-class thermal driver and use the
automatic hwmon functionality?
> + if (IS_ERR_VALUE(data->tz_dev)) {
> + dev_err(dev,
> + "failed to register %zu thermal sensor, err = %pe",
> + i, data->tz_dev);
If !CONFIG_OF || !CONFIG_THERMAL this will always log an error.
EOPNOTSUP should not trigger that logging.
> + continue;
> + }
> }
> }
>
> --
> 2.47.0.277.g8800431eea-goog
>
next prev parent reply other threads:[~2024-11-11 16:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 7:49 [PATCH] hwmon: (cros_ec) register thermal sensors to thermal framework Sung-Chi, Li
2024-11-11 8:16 ` Thomas Weißschuh
2024-11-11 9:50 ` [PATCH v2] " Sung-Chi
2024-11-11 9:50 ` [PATCH v2 2/2] dt-bindings: mfd: Add properties for thermal sensor cells Sung-Chi
2024-11-11 20:08 ` Conor Dooley
2024-11-11 16:30 ` Thomas Weißschuh [this message]
2024-11-11 17:01 ` [PATCH v2] hwmon: (cros_ec) register thermal sensors to thermal framework Guenter Roeck
2024-11-12 7:42 ` Sung-Chi, Li
2024-11-13 2:39 ` [PATCH v3 1/2] " Sung-Chi, Li
2024-11-13 2:39 ` [PATCH v3 2/2] dt-bindings: mfd: Add properties for thermal sensor cells Sung-Chi, Li
2024-11-13 3:05 ` Guenter Roeck
2024-11-25 8:52 ` Krzysztof Kozlowski
2024-11-25 8:54 ` Krzysztof Kozlowski
2024-11-25 15:13 ` Guenter Roeck
2024-11-25 15:18 ` Krzysztof Kozlowski
2024-11-25 16:41 ` Guenter Roeck
2024-11-25 17:12 ` Krzysztof Kozlowski
2024-11-13 3:04 ` [PATCH v3 1/2] hwmon: (cros_ec) register thermal sensors to thermal framework Guenter Roeck
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=a469852b-4cbd-467c-89de-b1acf6de1402@t-8ch.de \
--to=thomas@weissschuh.net \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=groeck@chromium.org \
--cc=jdelvare@suse.com \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lschyi@chromium.org \
--cc=robh@kernel.org \
/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