From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<arm-scmi@vger.kernel.org>, <sudeep.holla@arm.com>,
<james.quinlan@broadcom.com>, <f.fainelli@gmail.com>,
<vincent.guittot@linaro.org>, <etienne.carriere@st.com>,
<peng.fan@oss.nxp.com>, <michal.simek@amd.com>,
<quic_sibis@quicinc.com>, <dan.carpenter@linaro.org>,
<d-gole@ti.com>, <souvik.chakravarty@arm.com>
Subject: Re: [PATCH 05/10] firmware: arm_scmi: Add Telemetry protocol support
Date: Fri, 17 Oct 2025 16:37:25 +0100 [thread overview]
Message-ID: <20251017163725.0000149e@huawei.com> (raw)
In-Reply-To: <20250925203554.482371-6-cristian.marussi@arm.com>
On Thu, 25 Sep 2025 21:35:49 +0100
Cristian Marussi <cristian.marussi@arm.com> wrote:
> Add basic support for SCMI V4.0-alpha_0 Telemetry protocol including SHMTI,
> FastChannels, Notifications and Single Sample Reads collection methods.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Hi,
This is very much in the superficial drive by category as reviews
go. A few things noted but I've not looked at the code in enough
detail.
Jonathan
> diff --git a/drivers/firmware/arm_scmi/telemetry.c b/drivers/firmware/arm_scmi/telemetry.c
> new file mode 100644
> index 000000000000..f03000c173c2
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/telemetry.c
> @@ -0,0 +1,2117 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * System Control and Management Interface (SCMI) Telemetry Protocol
> + *
> + * Copyright (C) 2025 ARM Ltd.
> + *
My favorite trivial comment applies. What does this blank line add
to readability? I'd drop it.
> + */
> +
> +struct scmi_de_desc {
> + __le32 id;
> + __le32 grp_id;
> + __le32 data_sz;
> + __le32 attr_1;
> +#define IS_NAME_SUPPORTED(d) ((d)->attr_1 & BIT(31))
> +#define IS_FC_SUPPORTED(d) ((d)->attr_1 & BIT(30))
> +#define GET_DE_TYPE(d) (le32_get_bits((d)->attr_1, GENMASK(29, 22)))
> +#define IS_PERSISTENT(d) ((d)->attr_1 & BIT(21))
> +#define GET_DE_UNIT_EXP(d) \
> + ({ \
> + int __signed_exp = \
> + le32_get_bits((d)->attr_1, GENMASK(20, 13)); \
> + \
> + if (__signed_exp & BIT(7)) \
> + __signed_exp |= GENMASK(31, 8); \
> + __signed_exp; \
> + })
> +#define GET_DE_UNIT(d) (le32_get_bits((d)->attr_1, GENMASK(12, 5)))
> +
> +#define GET_DE_TSTAMP_EXP(d) \
> + ({ \
> + int __signed_exp = \
> + FIELD_GET(GENMASK(4, 1), (d)->attr_1); \
> + \
> + if (__signed_exp & BIT(3)) \
> + __signed_exp |= GENMASK(31, 4); \
> + __signed_exp; \
See below for sign_extend32() using code to replace these.
> +
> +struct scmi_msg_resp_telemetry_reading_complete {
> + __le32 num_dwords;
> + __le32 dwords[];
__counted_by(num_word);
> +};
> +
> +/* TDCF */
> +
> +#define TO_CPU_64(h, l) (((u64)le32_to_cpu((h)) << 32) | le32_to_cpu((l)))
Some of this stuff sounds very generic and isn't at all.
Personally I think I'd just drop this one as it may be better to see
the implementation wherever it is used.
> +static int scmi_telemetry_tdcf_line_parse(struct telemetry_info *ti,
> + struct payload __iomem *payld,
> + struct telemetry_shmti *shmti,
> + bool update)
> +{
> + int used_qwords;
> +
> + used_qwords = (USE_LINE_TS(payld) && TS_VALID(payld)) ?
> + QWORDS_TS_LINE_DATA_PAYLD : QWORDS_LINE_DATA_PAYLD;
> +
> + /*Invalid lines are not an error, could simply be disabled DEs */
Check for inconsistent comment syntax etc.
> + if (DATA_INVALID(payld))
> + return used_qwords;
> +
> +static int scmi_telemetry_shmti_scan(struct telemetry_info *ti,
> + unsigned int shmti_id, u64 ts,
> + bool update)
> +{
> + struct telemetry_shmti *shmti = &ti->shmti[shmti_id];
> + struct tdcf __iomem *tdcf = shmti->base;
> + int retries = SCMI_TLM_TDCF_MAX_RETRIES;
> + u64 startm = 0, endm = 0xffffffffffffffff;
No one likes counting fs. Use a GENMASK probably.
> + void *eplg = SHMTI_EPLG(shmti);
> +static void
> +scmi_telemetry_msg_payld_process(struct telemetry_info *ti,
> + unsigned int num_dwords, unsigned int *dwords,
I'd kind of expect something called dwords to have a fixed size. u32, u64 or
whatever.
> + ktime_t timestamp)
> +{
> + u32 next = 0;
> +
> + while (next < num_dwords) {
> + struct payload *payld = (struct payload *)&dwords[next];
> + struct scmi_telemetry_de *de;
> + struct telemetry_de *tde;
> + u32 de_id;
> +
> + next += USE_LINE_TS(payld) ?
> + TS_LINE_DATA_PAYLD_WORDS : LINE_DATA_PAYLD_WORDS;
> +
> + if (DATA_INVALID(payld)) {
> + dev_err(ti->dev, "MSG - Received INVALID DATA line\n");
> + continue;
> + }
> +
> + de_id = le32_to_cpu(payld->id);
> + de = xa_load(&ti->xa_des, de_id);
> + if (!de || !de->enabled) {
> + dev_err(ti->dev,
> + "MSG - Received INVALID DE - ID:%u enabled:%d\n",
> + de_id, de ? (de->enabled ? 'Y' : 'N') : 'X');
> + continue;
> + }
> +
> + tde = to_tde(de);
> + guard(mutex)(&tde->mtx);
> + tde->cached = true;
> + tde->last_val = LINE_DATA_GET(&payld->tsl);
> + //TODO BLK_TS in notification payloads
> + if (USE_LINE_TS(payld) && TS_VALID(payld))
> + tde->last_ts = LINE_TSTAMP_GET(&payld->tsl);
> + else
> + tde->last_ts = 0;
> + }
> +}
> diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
> index 59527193d6dd..6c6db95d0089 100644
> --- a/include/linux/scmi_protocol.h
> +++ b/include/linux/scmi_protocol.h
...
> +#define SCMI_TLM_GET_UPDATE_INTERVAL_SECS(x) \
> + (le32_get_bits((x), GENMASK(20, 5)))
Why is this one little endian specific and the next just uses assumption of
CPU Endian?
> +#define SCMI_TLM_GET_UPDATE_INTERVAL_EXP(x) \
> + ({ \
> + int __signed_exp = FIELD_GET(GENMASK(4, 0), (x)); \
> + \
> + if (__signed_exp & BIT(4)) \
> + __signed_exp |= GENMASK(31, 5); \
sign_extend32() from bitops.h should work here and is much more self explanatory.
That would then make this something like
#define SCMI_TLM_GET_UPDATE_INTERVAL_EXP(x) \
sign_extend32(x, 4);
or you can mask it first if you like but I don't think it makes any difference
in practice.
> + __signed_exp; \
> + })
> +
> +#define SCMI_TLM_BUILD_UPDATE_INTERVAL(s, e) \
> + (FIELD_PREP(GENMASK(20, 5), (s)) | FIELD_PREP(GENMASK(4, 0), (e)))
> +
> +struct scmi_telemetry_update_report {
> + ktime_t timestamp;
> + unsigned int agent_id;
> + int status;
> + unsigned int num_dwords;
> + unsigned int dwords[];
More places where __counted_by is appropriate. I'll not comment on any others and
just assume you'll add them wherever appropriate.
> +};
next prev parent reply other threads:[~2025-10-17 15:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-25 20:35 [PATCH 00/10] Introduce SCMI Telemetry support Cristian Marussi
2025-09-25 20:35 ` [PATCH 01/10] firmware: arm_scmi: Define a common SCMI_MAX_PROTOCOLS value Cristian Marussi
2025-09-25 20:35 ` [PATCH 02/10] firmware: arm_scmi: Reduce the scope of protocols mutex Cristian Marussi
2025-10-17 15:07 ` Jonathan Cameron
2025-10-21 9:36 ` Cristian Marussi
2025-09-25 20:35 ` [PATCH 03/10] firmware: arm_scmi: Allow protocols to register for notifications Cristian Marussi
2025-10-17 15:10 ` Jonathan Cameron
2025-10-21 9:37 ` Cristian Marussi
2025-09-25 20:35 ` [PATCH 04/10] uapi: Add ARM SCMI definitions Cristian Marussi
2025-09-26 14:30 ` kernel test robot
2025-10-17 15:14 ` Jonathan Cameron
2025-10-21 9:40 ` Cristian Marussi
2025-09-25 20:35 ` [PATCH 05/10] firmware: arm_scmi: Add Telemetry protocol support Cristian Marussi
2025-09-26 17:27 ` kernel test robot
2025-10-17 15:37 ` Jonathan Cameron [this message]
2025-10-21 10:08 ` Cristian Marussi
2025-10-28 11:43 ` Lukasz Luba
2025-10-28 17:51 ` Cristian Marussi
2025-09-25 20:35 ` [PATCH 06/10] firmware: arm_scmi: Add System Telemetry driver Cristian Marussi
2025-10-20 16:23 ` Jonathan Cameron
2025-10-21 10:27 ` Cristian Marussi
2025-10-21 15:15 ` Jonathan Cameron
2025-10-21 16:03 ` Cristian Marussi
2025-10-24 10:33 ` Jonathan Cameron
2025-09-25 20:35 ` [PATCH 07/10] firmware: arm_scmi: Add System Telemetry ioctls support Cristian Marussi
2025-10-20 16:30 ` Jonathan Cameron
2025-10-21 10:30 ` Cristian Marussi
2025-09-25 20:35 ` [PATCH 08/10] firmware: arm_scmi: Add Telemetry components view Cristian Marussi
2025-09-25 20:35 ` [PATCH 09/10] include: trace: Add Telemetry trace events Cristian Marussi
2025-09-25 20:35 ` [PATCH 10/10] firmware: arm_scmi: Use new Telemetry traces Cristian Marussi
2025-09-26 13:05 ` kernel test robot
2025-09-26 19:54 ` kernel test robot
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=20251017163725.0000149e@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=d-gole@ti.com \
--cc=dan.carpenter@linaro.org \
--cc=etienne.carriere@st.com \
--cc=f.fainelli@gmail.com \
--cc=james.quinlan@broadcom.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=peng.fan@oss.nxp.com \
--cc=quic_sibis@quicinc.com \
--cc=souvik.chakravarty@arm.com \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.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 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.