From: Peng Fan <peng.fan@oss.nxp.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: Peng Fan <peng.fan@nxp.com>, Sudeep Holla <sudeep.holla@arm.com>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
arm-scmi@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/7] firmware: imx: sm-misc: Dump syslog and system info
Date: Mon, 30 Jun 2025 11:34:56 +0800 [thread overview]
Message-ID: <20250630033456.GE13878@nxa18884-linux> (raw)
In-Reply-To: <aF6md8uMuD8EpXvd@pluto>
On Fri, Jun 27, 2025 at 03:11:03PM +0100, Cristian Marussi wrote:
>On Fri, Jun 27, 2025 at 02:03:50PM +0800, Peng Fan wrote:
>> Add sysfs interface to read System Manager syslog and system info
>>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> drivers/firmware/imx/sm-misc.c | 97 ++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 97 insertions(+)
>>
>> diff --git a/drivers/firmware/imx/sm-misc.c b/drivers/firmware/imx/sm-misc.c
>> index fc3ee12c2be878e0285183e3381c9514a63d5142..55485a3c4a5c615102a377f41025a6911d746770 100644
>> --- a/drivers/firmware/imx/sm-misc.c
>> +++ b/drivers/firmware/imx/sm-misc.c
>> @@ -44,6 +44,100 @@ static int scmi_imx_misc_ctrl_notifier(struct notifier_block *nb,
>> return 0;
>> }
>>
>> +static ssize_t syslog_show(struct device *device, struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct scmi_imx_misc_sys_sleep_rec *rec;
>> + struct scmi_imx_misc_syslog *syslog;
>> + int ret;
>> + size_t len = 0;
>> +
>> + if (!ph)
>> + return 0;
>> +
>> + syslog = kmalloc(sizeof(*syslog), GFP_KERNEL);
>> + if (!syslog)
>> + return -ENOMEM;
>> +
>> + ret = imx_misc_ctrl_ops->misc_syslog(ph, sizeof(*syslog), syslog);
>
>...ah...so you basically cast to void a structure of u32 words and then
>expect that the firmware perfectly aligned with how the struct is
>defined here....size checks assures no out-of-bounds BUT the meaning of
>he blob itself is entirely up to FW and kernel being aligned, since no
>type checking is done of any kind and fields are NOT reference by
>name...so may I ask why ?
I thought to use "u32 *syslog", but this needs a cast in
misc_syslog(x,y,(u32 *)syslog), or I could directly change
the misc_syslog function prototype to use 'struct scmi_imx_misc_syslog *'.
No specific reason, just think 'void *' could avoid a cast.
..also because the scmi_imx_misc_syslog seems
>pretty tiny to need iterators to parse back the reply...do you have so
>tiny transpotr message size ?
The transport memory size is 0x80 bytes, it could cover the current
syslog, but I am not sure whether in future, the firmware could
extend to add more information.
In our firmware there is one more field that I not include in this patchset,
because it is default not built in in firmware:
typedef struct
{
/*! System sleep record */
dev_sm_sys_sleep_rec_t sysSleepRecord;
/*! Device error log */
uint32_t devErrLog;
#ifdef DEV_SM_MSG_PROF_CNT
/*! Message profiling record */
dev_sm_sys_msg_rec_t sysMsgRecord;
#endif
} dev_sm_syslog_t;
typedef struct
{
uint32_t scmiChannel; /*!< Caller SCMI channel */
uint32_t chanType; /*!< SCMI channel type */
uint32_t protocolId; /*!< SCMI protocol ID */
uint32_t msgId; /*!< SCMI message ID */
uint32_t msgLatUsec; /*!< Message latency */
} dev_sm_sys_msg_prof_t;
/*!
* Message profile record
*/
typedef struct
{
/*! MSG profile log */
dev_sm_sys_msg_prof_t msgProf[DEV_SM_MSG_PROF_CNT];
} dev_sm_sys_msg_rec_t;
With profiling, we need iterator to get all the information.
In our default FW build, DEV_SM_MSG_PROF_CNT is not defined, but
I could keep iterator in case DEV_SM_MSG_PROF_CNT enabled in future.
>
>..anyway I would suggest at least to add some sort of version-field to
>the struct so that at least you can detect if the FW spits out something
>that is not what your driver expect or is ready to handle...especially
>if you plan to extend or modify the layout of the structs in the future.
Would you please share more insights on what version is needed here?
You mean add a field for syslog protocol as below?
struct scmi_imx_misc_syslog {
uint32_t version; //Set as protocol version and display it in sysfs show ops?
struct scmi_imx_misc_sys_sleep_rec syssleeprecord;
uint32_t deverrlog;
};
>
>
>> + if (ret) {
>> + kfree(syslog);
>> + return ret;
>> + }
>> +
>> + rec = &syslog->syssleeprecord;
>> +
>> + len += sysfs_emit_at(buf, len, "Wake Vector = %u\n", rec->wakesource);
>> + len += sysfs_emit_at(buf, len, "Sys sleep mode = %u\n", rec->syssleepmode);
>> + len += sysfs_emit_at(buf, len, "Sys sleep flags = 0x%08x\n", rec->syssleepflags);
>> + len += sysfs_emit_at(buf, len, "MIX power status = 0x%08x\n", rec->mixpwrstat);
>> + len += sysfs_emit_at(buf, len, "MEM power status = 0x%08x\n", rec->mempwrstat);
>> + len += sysfs_emit_at(buf, len, "PLL power status = 0x%08x\n", rec->pllpwrstat);
>> + len += sysfs_emit_at(buf, len, "Sleep latency = %u\n", rec->sleepentryusec);
>> + len += sysfs_emit_at(buf, len, "Wake latency = %u\n", rec->sleepexitusec);
>> + len += sysfs_emit_at(buf, len, "Sleep count = %u\n", rec->sleepcnt);
>> +
>
>... how wonder how much is still frowned upon to serve such big multiline
>structured information payloads from sysfs ... (asking for a friend :P)
Just take what our firmware console displays.
And in case the firmware does not have a dedicated uart on some
boards, using syslog to show similar info would be prefered,
so ...
>
>
>> + kfree(syslog);
>> +
>> + return len;
>> +}
>> +
>> +static DEVICE_ATTR_RO(syslog);
>> +
>> +static ssize_t system_info_show(struct device *device, struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct scmi_imx_misc_system_info *info;
>> + int len = 0;
>> + int ret;
>> +
>> + if (!ph)
>> + return 0;
>> +
>> + info = kmalloc(sizeof(*info), GFP_KERNEL);
>> + if (!info)
>> + return -ENOMEM;
>> +
>> + ret = imx_misc_ctrl_ops->misc_discover_build_info(ph, info);
>> + if (ret)
>> + goto err;
>> +
>> + ret = imx_misc_ctrl_ops->misc_cfg_info(ph, info);
>> + if (ret)
>> + goto err;
>> +
>> + ret = imx_misc_ctrl_ops->misc_silicon_info(ph, info);
>> + if (ret)
>> + goto err;
>> +
>> + ret = imx_misc_ctrl_ops->misc_board_info(ph, info);
>> + if (ret)
>> + goto err;
>> +
>> + len += sysfs_emit_at(buf, len, "SM Version = Build %u, Commit 08%x\n",
>> + info->buildnum, info->buildcommit);
>> + len += sysfs_emit_at(buf, len, "SM Config = %s, mSel=%u\n",
>> + info->cfgname, info->msel);
>> + len += sysfs_emit_at(buf, len, "Silicon = %s\n", info->siname);
>> + len += sysfs_emit_at(buf, len, "Board = %s, attr=0x%08x\n",
>> + info->brdname, info->brd_attributes);
>
>...so some of this stuff Build/Silicon/BoaRD info has pretty much
>'forever' lifetime...are you sure you want to query them out of the FW
>each time you issue a sysfs show ?
>
>Cannot you simply dump this stuff once for all at probve time and
>instead query misc_cfg_info() upon each show to refresh only the data
>that will change ?
>
>(this also corroborates my idea that you should somehow partition this
>data into distinct structs by their lifetime...
In next version, I will change to use probe to query the information and
use sysfs to give userspace an interface to get the queried information.
Thanks,
Peng
>
>Thanks,
>Cristian
next prev parent reply other threads:[~2025-06-30 2:24 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 6:03 [PATCH 0/7] firmware: arm_scmi: imx: Dump syslog and system_info Peng Fan
2025-06-27 6:03 ` [PATCH 1/7] firmware: arm_scmi: imx: Add documentation for MISC_BOARD_INFO Peng Fan
2025-06-27 12:46 ` Cristian Marussi
2025-06-30 2:45 ` Peng Fan
2025-07-01 15:10 ` Peng Fan
2025-07-02 15:21 ` Sudeep Holla
2025-07-04 4:53 ` Peng Fan
2025-06-27 6:03 ` [PATCH 2/7] firmware: arm_scmi: imx: Support discovering buildinfo of MISC protocol Peng Fan
2025-06-27 12:48 ` Cristian Marussi
2025-07-02 15:21 ` Sudeep Holla
2025-07-04 5:12 ` Peng Fan
2025-07-04 8:59 ` Sudeep Holla
2025-07-08 16:10 ` Peng Fan
2025-07-08 15:38 ` Sudeep Holla
2025-06-27 6:03 ` [PATCH 3/7] firmware: arm_scmi: imx: Support getting cfg info " Peng Fan
2025-06-27 13:06 ` Cristian Marussi
2025-07-02 15:21 ` Sudeep Holla
2025-07-04 10:07 ` Peng Fan
2025-07-04 9:02 ` Sudeep Holla
2025-07-04 10:39 ` Peng Fan
2025-07-04 10:51 ` Sudeep Holla
2025-06-27 6:03 ` [PATCH 4/7] firmware: arm_scmi: imx: Support getting silicon " Peng Fan
2025-06-27 13:11 ` Cristian Marussi
2025-07-02 15:22 ` Sudeep Holla
2025-07-04 10:20 ` Peng Fan
2025-07-04 9:32 ` Sudeep Holla
2025-06-27 6:03 ` [PATCH 5/7] firmware: arm_scmi: imx: Support getting syslog " Peng Fan
2025-06-27 13:44 ` Cristian Marussi
2025-06-30 3:09 ` Peng Fan
2025-07-02 15:22 ` Sudeep Holla
2025-07-04 10:23 ` Peng Fan
2025-07-04 9:44 ` Sudeep Holla
2025-06-27 6:03 ` [PATCH 6/7] firmware: arm_scmi: imx: Support getting board info " Peng Fan
2025-06-27 13:45 ` Cristian Marussi
2025-06-30 2:50 ` Peng Fan
2025-06-27 6:03 ` [PATCH 7/7] firmware: imx: sm-misc: Dump syslog and system info Peng Fan
2025-06-27 14:11 ` Cristian Marussi
2025-06-30 3:34 ` Peng Fan [this message]
2025-06-27 18:49 ` kernel test robot
2025-06-28 14:28 ` kernel test robot
2025-07-02 15:22 ` Sudeep Holla
2025-07-04 10:28 ` Peng Fan
2025-07-04 9:45 ` Sudeep Holla
2025-07-04 10:44 ` 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=20250630033456.GE13878@nxa18884-linux \
--to=peng.fan@oss.nxp.com \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--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 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.