From: Cristian Marussi <cristian.marussi@arm.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Peng Fan <peng.fan@nxp.com>,
"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
"groeck7@gmail.com" <groeck7@gmail.com>,
"sudeep.holla@arm.com" <sudeep.holla@arm.com>,
"jdelvare@suse.com" <jdelvare@suse.com>,
"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3] hwmon: scmi-hwmon: implement change_mode for thermal zones
Date: Thu, 25 Jan 2024 16:09:08 +0000 [thread overview]
Message-ID: <ZbKHpFRGoaQpWX16@pluto> (raw)
In-Reply-To: <540cf4b3-ebf6-4a85-84c4-c012a69db416@roeck-us.net>
On Thu, Jan 25, 2024 at 06:25:00AM -0800, Guenter Roeck wrote:
> On 1/24/24 23:06, Peng Fan wrote:
> > Hi Guenter,
> >
> > > Subject: Re: [PATCH V3] hwmon: scmi-hwmon: implement change_mode for
> > > thermal zones
> > >
> > > On 1/24/24 22:44, Peng Fan (OSS) wrote:
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > >
> > > > The thermal sensors maybe disabled before kernel boot, so add
> > > > change_mode for thermal zones to support configuring the thermal
> > > > sensor to enabled state. If reading the temperature when the sensor is
> > > > disabled, there will be error reported.
> > > >
> > > > The cost is an extra config_get all to SCMI firmware to get the status
> > > > of the thermal sensor. No function level impact.
> > > >
> > > > Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > >
> > > > V3:
> > > > Update commit log to show it only applys to thermal
> > > > Add comments in code
> > > > Add R-b from Cristian
> > > >
> > >
> > > You didn't address my question regarding the behavior of hwmon attributes if
> > > a sensor is disabled.
> >
> > Would you please share a bit more on what attributes?
> > You mean the files under /sys/class/hwmon/hwmon0?
> >
> > If the sensor is disabled, when cat temp[x]_input, it will
> > report:
> > root@imx95-19x19-lpddr5-evk:/sys/class/hwmon/hwmon0# cat temp3_input
> > cat: temp3_input: Protocol error
> >
> > For enabled, it will report value:
> > root@imx95-19x19-lpddr5-evk:/sys/class/hwmon/hwmon0# cat temp1_input
> > 31900
> >
>
> This is wrong. If the sensor is disabled, there should either be no
> sensor attribute (if the condition is permanent), or there should be
> tempX_enable attribute(s) which return the sensor status (and, if
> appropriate, permit it to be enabled). If the condition is not
> permanent, attempts to read the sensor value should return -ENODATA.
>
If the sensor is permanently disabled it should not have been exposed by
the SCMI server at all, in first place; in such a case it wont appear at
all in hwmon.
In this case seems like the sensor is NOT supposed to be ever disabled
(not even temporarily), it it just that you want to ensure that is
enabled, so I would say @Peng, should not that be done in the fw
SCMI server ? (i.e. to turn on, early on, all those resources that are
exposed to the agent and meant to be always on)
Regarding the non-permanent condition, currently if the SCMI reading
failed, for some reason, we return the same error as returned from the
SCMI layer, so I suppose I should post a patch to remap that return
value to -ENODATA.
> Overall, hwmon functionality is orthogonal to thermal subsystem use.
> It is not appropriate for the thermal subsystem to disable any
> temperature sensors in the hwmon subsystem because the user might
> expect to be able to read temperatures from hwmon devices even
> if sensors are not in use by the thermal subsystem.
Agreed, but it seems that indeed here the attempt is to make sure that
an accidentally disabled sensor is turned on.
Thanks,
Cristian
next prev parent reply other threads:[~2024-01-25 16:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-25 6:44 [PATCH V3] hwmon: scmi-hwmon: implement change_mode for thermal zones Peng Fan (OSS)
2024-01-25 6:54 ` Guenter Roeck
2024-01-25 7:06 ` Peng Fan
2024-01-25 9:45 ` Cristian Marussi
2024-01-25 14:25 ` Guenter Roeck
2024-01-25 16:09 ` Cristian Marussi [this message]
2024-01-25 16:16 ` Guenter Roeck
2024-01-25 16:57 ` Cristian Marussi
2024-05-14 2:53 ` Peng Fan
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=ZbKHpFRGoaQpWX16@pluto \
--to=cristian.marussi@arm.com \
--cc=groeck7@gmail.com \
--cc=jdelvare@suse.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=peng.fan@nxp.com \
--cc=peng.fan@oss.nxp.com \
--cc=sudeep.holla@arm.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