MISC protocol supports getting the silicon information including revision
number, part number and etc. Add the API for user to retrieve the
information from SM.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
.../firmware/arm_scmi/vendors/imx/imx-sm-misc.c | 34 ++++++++++++++++++++++
include/linux/scmi_imx_protocol.h | 8 +++++
2 files changed, 42 insertions(+)
diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
index 8ce4bf92e6535af2f30d72a34717678613b35049..d5b24bc4d4ca6c19f4cddfaea6e9d9b32a4c92f7 100644
--- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
+++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
@@ -26,6 +26,7 @@ enum scmi_imx_misc_protocol_cmd {
SCMI_IMX_MISC_CTRL_SET = 0x3,
SCMI_IMX_MISC_CTRL_GET = 0x4,
SCMI_IMX_MISC_DISCOVER_BUILDINFO = 0x6,
+ SCMI_IMX_MISC_SI_INFO = 0xB,
SCMI_IMX_MISC_CFG_INFO = 0xC,
SCMI_IMX_MISC_CTRL_NOTIFY = 0x8,
};
@@ -79,6 +80,13 @@ struct scmi_imx_misc_cfg_info_out {
u8 cfgname[MISC_MAX_CFGNAME];
};
+struct scmi_imx_misc_si_info_out {
+ __le32 deviceid;
+ __le32 sirev;
+ __le32 partnum;
+ u8 siname[MISC_MAX_SINAME];
+};
+
static int scmi_imx_misc_attributes_get(const struct scmi_protocol_handle *ph,
struct scmi_imx_misc_info *mi)
{
@@ -335,12 +343,38 @@ static int scmi_imx_misc_cfg_info(const struct scmi_protocol_handle *ph,
return ret;
}
+static int scmi_imx_misc_silicon_info(const struct scmi_protocol_handle *ph,
+ struct scmi_imx_misc_system_info *info)
+{
+ struct scmi_imx_misc_si_info_out *out;
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_MISC_SI_INFO, 0, sizeof(*out), &t);
+ if (ret)
+ return ret;
+
+ ret = ph->xops->do_xfer(ph, t);
+ if (!ret) {
+ out = t->rx.buf;
+ info->deviceid = le32_to_cpu(out->deviceid);
+ info->sirev = le32_to_cpu(out->sirev);
+ info->partnum = le32_to_cpu(out->partnum);
+ strscpy(info->siname, out->siname, MISC_MAX_SINAME);
+ }
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
static const struct scmi_imx_misc_proto_ops scmi_imx_misc_proto_ops = {
.misc_cfg_info = scmi_imx_misc_cfg_info,
.misc_ctrl_set = scmi_imx_misc_ctrl_set,
.misc_ctrl_get = scmi_imx_misc_ctrl_get,
.misc_ctrl_req_notify = scmi_imx_misc_ctrl_notify,
.misc_discover_build_info = scmi_imx_discover_build_info,
+ .misc_silicon_info = scmi_imx_misc_silicon_info,
};
static int scmi_imx_misc_protocol_init(const struct scmi_protocol_handle *ph)
diff --git a/include/linux/scmi_imx_protocol.h b/include/linux/scmi_imx_protocol.h
index bb0c35b5d6705acddd6c83c31474482a2667b418..0e639dfb5d16e281e2ccf006a63694b316c431f4 100644
--- a/include/linux/scmi_imx_protocol.h
+++ b/include/linux/scmi_imx_protocol.h
@@ -55,6 +55,7 @@ struct scmi_imx_misc_ctrl_notify_report {
#define MISC_MAX_BUILDDATE 16
#define MISC_MAX_BUILDTIME 16
#define MISC_MAX_CFGNAME 16
+#define MISC_MAX_SINAME 16
struct scmi_imx_misc_system_info {
u32 buildnum;
@@ -63,6 +64,11 @@ struct scmi_imx_misc_system_info {
u8 time[MISC_MAX_BUILDTIME];
u32 msel;
u8 cfgname[MISC_MAX_CFGNAME];
+ /* silicon */
+ u32 deviceid;
+ u32 sirev;
+ u32 partnum;
+ u8 siname[MISC_MAX_SINAME];
};
struct scmi_imx_misc_proto_ops {
@@ -76,6 +82,8 @@ struct scmi_imx_misc_proto_ops {
u32 ctrl_id, u32 evt_id, u32 flags);
int (*misc_discover_build_info)(const struct scmi_protocol_handle *ph,
struct scmi_imx_misc_system_info *info);
+ int (*misc_silicon_info)(const struct scmi_protocol_handle *ph,
+ struct scmi_imx_misc_system_info *info);
};
/* See LMM_ATTRIBUTES in imx95.rst */
--
2.37.1On Fri, Jun 27, 2025 at 02:03:47PM +0800, Peng Fan wrote:
> MISC protocol supports getting the silicon information including revision
> number, part number and etc. Add the API for user to retrieve the
> information from SM.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> .../firmware/arm_scmi/vendors/imx/imx-sm-misc.c | 34 ++++++++++++++++++++++
> include/linux/scmi_imx_protocol.h | 8 +++++
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> index 8ce4bf92e6535af2f30d72a34717678613b35049..d5b24bc4d4ca6c19f4cddfaea6e9d9b32a4c92f7 100644
> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> @@ -26,6 +26,7 @@ enum scmi_imx_misc_protocol_cmd {
> SCMI_IMX_MISC_CTRL_SET = 0x3,
> SCMI_IMX_MISC_CTRL_GET = 0x4,
> SCMI_IMX_MISC_DISCOVER_BUILDINFO = 0x6,
> + SCMI_IMX_MISC_SI_INFO = 0xB,
Again, this seem to have slipped through in my initial review. How is this
different from SMCCC SOC_ID interface. I am OK to have it as part of your
vendor extensions and be here in the kernel documentation. But I won't
accept any users of this within the kernel. Please provide justification
as why you can't use the standard SMCCC SOC_ID.
So, clear NACK for adding this support in the kernel for now.
It is pretty useless to push this to userspace with custom interface.
Use the existing interface with SOC_ID. Also the way I would think this
interface may be used is from SMCCC interface implementation which could
retrieve info via this interface but that would be just platform specific
code in the firmware.
--
Regards,
Sudeep
On Wed, Jul 02, 2025 at 04:22:11PM +0100, Sudeep Holla wrote:
>On Fri, Jun 27, 2025 at 02:03:47PM +0800, Peng Fan wrote:
>> MISC protocol supports getting the silicon information including revision
>> number, part number and etc. Add the API for user to retrieve the
>> information from SM.
>>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> .../firmware/arm_scmi/vendors/imx/imx-sm-misc.c | 34 ++++++++++++++++++++++
>> include/linux/scmi_imx_protocol.h | 8 +++++
>> 2 files changed, 42 insertions(+)
>>
>> diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
>> index 8ce4bf92e6535af2f30d72a34717678613b35049..d5b24bc4d4ca6c19f4cddfaea6e9d9b32a4c92f7 100644
>> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
>> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
>> @@ -26,6 +26,7 @@ enum scmi_imx_misc_protocol_cmd {
>> SCMI_IMX_MISC_CTRL_SET = 0x3,
>> SCMI_IMX_MISC_CTRL_GET = 0x4,
>> SCMI_IMX_MISC_DISCOVER_BUILDINFO = 0x6,
>> + SCMI_IMX_MISC_SI_INFO = 0xB,
>
>Again, this seem to have slipped through in my initial review. How is this
>different from SMCCC SOC_ID interface. I am OK to have it as part of your
>vendor extensions and be here in the kernel documentation. But I won't
>accept any users of this within the kernel. Please provide justification
>as why you can't use the standard SMCCC SOC_ID.
>
>So, clear NACK for adding this support in the kernel for now.
What I do here is just wanna to let
linux could print similar information as what SM shows in its console:
>$ info
SM Version = Build 677, Commit 49a36aaf
SM Config = mx95evk, mSel=0
Board = i.MX95 EVK, attr=0x00000000
Silicon = i.MX95 B0
Boot mode = normal
Boot device = SD2
Boot stage = primary
Boot set = 1
ECID = 0x7BADEECC000001D40001300963E636F1
PMIC 0 (0x08) = 0x20, 0x09, 0x20, 0x00, 0x01
PMIC 1 (0x2A) = 0x54, 0x22, 0x00, 0x0B
PMIC 2 (0x29) = 0x55, 0x22, 0x00, 0x0A
Compiler = gcc 14.2.1 20241119
With soc_device_register, dumping the silicon information needs use the
other sysfs interface. Here with this patchset, reading one sysfs file could
dump all the information.
But anyway, ok to drop this patch.
Thanks,
Peng
On Fri, Jul 04, 2025 at 06:20:57PM +0800, Peng Fan wrote:
> On Wed, Jul 02, 2025 at 04:22:11PM +0100, Sudeep Holla wrote:
> >On Fri, Jun 27, 2025 at 02:03:47PM +0800, Peng Fan wrote:
> >> MISC protocol supports getting the silicon information including revision
> >> number, part number and etc. Add the API for user to retrieve the
> >> information from SM.
> >>
> >> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> >> ---
> >> .../firmware/arm_scmi/vendors/imx/imx-sm-misc.c | 34 ++++++++++++++++++++++
> >> include/linux/scmi_imx_protocol.h | 8 +++++
> >> 2 files changed, 42 insertions(+)
> >>
> >> diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> >> index 8ce4bf92e6535af2f30d72a34717678613b35049..d5b24bc4d4ca6c19f4cddfaea6e9d9b32a4c92f7 100644
> >> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> >> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> >> @@ -26,6 +26,7 @@ enum scmi_imx_misc_protocol_cmd {
> >> SCMI_IMX_MISC_CTRL_SET = 0x3,
> >> SCMI_IMX_MISC_CTRL_GET = 0x4,
> >> SCMI_IMX_MISC_DISCOVER_BUILDINFO = 0x6,
> >> + SCMI_IMX_MISC_SI_INFO = 0xB,
> >
> >Again, this seem to have slipped through in my initial review. How is this
> >different from SMCCC SOC_ID interface. I am OK to have it as part of your
> >vendor extensions and be here in the kernel documentation. But I won't
> >accept any users of this within the kernel. Please provide justification
> >as why you can't use the standard SMCCC SOC_ID.
> >
> >So, clear NACK for adding this support in the kernel for now.
>
> What I do here is just wanna to let
> linux could print similar information as what SM shows in its console:
>
Sure you can dump whatever you want on the console. The main concern is
another user interface for very similar information that can be obtained
by SOC_ID or soc_device in the kernel. Just kernel internal use should
be fine.
> >$ info
> SM Version = Build 677, Commit 49a36aaf
> SM Config = mx95evk, mSel=0
> Board = i.MX95 EVK, attr=0x00000000
> Silicon = i.MX95 B0
> Boot mode = normal
> Boot device = SD2
> Boot stage = primary
> Boot set = 1
> ECID = 0x7BADEECC000001D40001300963E636F1
> PMIC 0 (0x08) = 0x20, 0x09, 0x20, 0x00, 0x01
> PMIC 1 (0x2A) = 0x54, 0x22, 0x00, 0x0B
> PMIC 2 (0x29) = 0x55, 0x22, 0x00, 0x0A
> Compiler = gcc 14.2.1 20241119
>
> With soc_device_register, dumping the silicon information needs use the
> other sysfs interface.
So what ?
> Here with this patchset, reading one sysfs file could dump all the information.
>
That goes completely again the sysfs policy. Single file single value.
Convince Greg otherwise, I will consider elsewhere not for this SOC_ID
for sure.
> But anyway, ok to drop this patch.
>
Thanks!
--
Regards,
Sudeep
On Fri, Jun 27, 2025 at 02:03:47PM +0800, Peng Fan wrote:
> MISC protocol supports getting the silicon information including revision
> number, part number and etc. Add the API for user to retrieve the
> information from SM.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> .../firmware/arm_scmi/vendors/imx/imx-sm-misc.c | 34 ++++++++++++++++++++++
> include/linux/scmi_imx_protocol.h | 8 +++++
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> index 8ce4bf92e6535af2f30d72a34717678613b35049..d5b24bc4d4ca6c19f4cddfaea6e9d9b32a4c92f7 100644
> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> @@ -26,6 +26,7 @@ enum scmi_imx_misc_protocol_cmd {
> SCMI_IMX_MISC_CTRL_SET = 0x3,
> SCMI_IMX_MISC_CTRL_GET = 0x4,
> SCMI_IMX_MISC_DISCOVER_BUILDINFO = 0x6,
> + SCMI_IMX_MISC_SI_INFO = 0xB,
> SCMI_IMX_MISC_CFG_INFO = 0xC,
> SCMI_IMX_MISC_CTRL_NOTIFY = 0x8,
> };
> @@ -79,6 +80,13 @@ struct scmi_imx_misc_cfg_info_out {
> u8 cfgname[MISC_MAX_CFGNAME];
> };
>
> +struct scmi_imx_misc_si_info_out {
> + __le32 deviceid;
> + __le32 sirev;
> + __le32 partnum;
> + u8 siname[MISC_MAX_SINAME];
> +};
> +
> static int scmi_imx_misc_attributes_get(const struct scmi_protocol_handle *ph,
> struct scmi_imx_misc_info *mi)
> {
> @@ -335,12 +343,38 @@ static int scmi_imx_misc_cfg_info(const struct scmi_protocol_handle *ph,
> return ret;
> }
>
> +static int scmi_imx_misc_silicon_info(const struct scmi_protocol_handle *ph,
> + struct scmi_imx_misc_system_info *info)
> +{
> + struct scmi_imx_misc_si_info_out *out;
> + struct scmi_xfer *t;
> + int ret;
> +
> + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_MISC_SI_INFO, 0, sizeof(*out), &t);
> + if (ret)
> + return ret;
> +
> + ret = ph->xops->do_xfer(ph, t);
> + if (!ret) {
> + out = t->rx.buf;
> + info->deviceid = le32_to_cpu(out->deviceid);
> + info->sirev = le32_to_cpu(out->sirev);
> + info->partnum = le32_to_cpu(out->partnum);
> + strscpy(info->siname, out->siname, MISC_MAX_SINAME);
> + }
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> static const struct scmi_imx_misc_proto_ops scmi_imx_misc_proto_ops = {
> .misc_cfg_info = scmi_imx_misc_cfg_info,
> .misc_ctrl_set = scmi_imx_misc_ctrl_set,
> .misc_ctrl_get = scmi_imx_misc_ctrl_get,
> .misc_ctrl_req_notify = scmi_imx_misc_ctrl_notify,
> .misc_discover_build_info = scmi_imx_discover_build_info,
> + .misc_silicon_info = scmi_imx_misc_silicon_info,
> };
>
> static int scmi_imx_misc_protocol_init(const struct scmi_protocol_handle *ph)
> diff --git a/include/linux/scmi_imx_protocol.h b/include/linux/scmi_imx_protocol.h
> index bb0c35b5d6705acddd6c83c31474482a2667b418..0e639dfb5d16e281e2ccf006a63694b316c431f4 100644
> --- a/include/linux/scmi_imx_protocol.h
> +++ b/include/linux/scmi_imx_protocol.h
> @@ -55,6 +55,7 @@ struct scmi_imx_misc_ctrl_notify_report {
> #define MISC_MAX_BUILDDATE 16
> #define MISC_MAX_BUILDTIME 16
> #define MISC_MAX_CFGNAME 16
> +#define MISC_MAX_SINAME 16
>
> struct scmi_imx_misc_system_info {
> u32 buildnum;
> @@ -63,6 +64,11 @@ struct scmi_imx_misc_system_info {
> u8 time[MISC_MAX_BUILDTIME];
> u32 msel;
> u8 cfgname[MISC_MAX_CFGNAME];
> + /* silicon */
> + u32 deviceid;
> + u32 sirev;
> + u32 partnum;
> + u8 siname[MISC_MAX_SINAME];
> };
Same observation here...maybe embed a struct dedicated to this....BUT in
this case the silicon_info are NOT meant to change during a boot (and
even across a reboot really) so why a distinct command from build_info
since both infos has the same lifetime ? (I understand the quality of
the info returned is drastically different HW vs SW)
>
> struct scmi_imx_misc_proto_ops {
> @@ -76,6 +82,8 @@ struct scmi_imx_misc_proto_ops {
> u32 ctrl_id, u32 evt_id, u32 flags);
> int (*misc_discover_build_info)(const struct scmi_protocol_handle *ph,
> struct scmi_imx_misc_system_info *info);
> + int (*misc_silicon_info)(const struct scmi_protocol_handle *ph,
> + struct scmi_imx_misc_system_info *info);
> };
>
> /* See LMM_ATTRIBUTES in imx95.rst */
Other than this, no strong opinion anyway.
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Thanks,
Cristian
© 2016 - 2025 Red Hat, Inc.