MISC protocol supports discovering the System Manager(SM) build
information including build commit, build time 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 | 35 ++++++++++++++++++++++
include/linux/scmi_imx_protocol.h | 12 ++++++++
2 files changed, 47 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 a8915d3b4df518719d56bfff38922625ad9b70f6..1b24d070c6f4856b92f515fcdba5836fd6498ce6 100644
--- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
+++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
@@ -25,6 +25,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_CTRL_NOTIFY = 0x8,
};
@@ -65,6 +66,13 @@ struct scmi_imx_misc_ctrl_get_out {
__le32 val[];
};
+struct scmi_imx_misc_buildinfo_out {
+ __le32 buildnum;
+ __le32 buildcommit;
+ u8 builddate[MISC_MAX_BUILDDATE];
+ u8 buildtime[MISC_MAX_BUILDTIME];
+};
+
static int scmi_imx_misc_attributes_get(const struct scmi_protocol_handle *ph,
struct scmi_imx_misc_info *mi)
{
@@ -272,10 +280,37 @@ static int scmi_imx_misc_ctrl_set(const struct scmi_protocol_handle *ph,
return ret;
}
+static int scmi_imx_discover_build_info(const struct scmi_protocol_handle *ph,
+ struct scmi_imx_misc_system_info *info)
+{
+ struct scmi_imx_misc_buildinfo_out *out;
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_MISC_DISCOVER_BUILDINFO, 0,
+ sizeof(*out), &t);
+ if (ret)
+ return ret;
+
+ ret = ph->xops->do_xfer(ph, t);
+ if (!ret) {
+ out = t->rx.buf;
+ info->buildnum = le32_to_cpu(out->buildnum);
+ info->buildcommit = le32_to_cpu(out->buildcommit);
+ strscpy(info->date, out->builddate, MISC_MAX_BUILDDATE);
+ strscpy(info->time, out->buildtime, MISC_MAX_BUILDTIME);
+ }
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
static const struct scmi_imx_misc_proto_ops scmi_imx_misc_proto_ops = {
.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,
};
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 27bd372cbfb142b6acb0b1cf4b82f061529d0d45..826402dfe6f4d3b9e6d2e93868d6699f989e9bcc 100644
--- a/include/linux/scmi_imx_protocol.h
+++ b/include/linux/scmi_imx_protocol.h
@@ -52,6 +52,16 @@ struct scmi_imx_misc_ctrl_notify_report {
unsigned int flags;
};
+#define MISC_MAX_BUILDDATE 16
+#define MISC_MAX_BUILDTIME 16
+
+struct scmi_imx_misc_system_info {
+ u32 buildnum;
+ u32 buildcommit;
+ u8 date[MISC_MAX_BUILDDATE];
+ u8 time[MISC_MAX_BUILDTIME];
+};
+
struct scmi_imx_misc_proto_ops {
int (*misc_ctrl_set)(const struct scmi_protocol_handle *ph, u32 id,
u32 num, u32 *val);
@@ -59,6 +69,8 @@ struct scmi_imx_misc_proto_ops {
u32 *num, u32 *val);
int (*misc_ctrl_req_notify)(const struct scmi_protocol_handle *ph,
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);
};
/* See LMM_ATTRIBUTES in imx95.rst */
--
2.37.1On Fri, Jun 27, 2025 at 02:03:45PM +0800, Peng Fan wrote:
> MISC protocol supports discovering the System Manager(SM) build
> information including build commit, build time 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 | 35 ++++++++++++++++++++++
> include/linux/scmi_imx_protocol.h | 12 ++++++++
> 2 files changed, 47 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 a8915d3b4df518719d56bfff38922625ad9b70f6..1b24d070c6f4856b92f515fcdba5836fd6498ce6 100644
> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> @@ -25,6 +25,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,
I clearly missed to raise this point when the documentation for this command
was added. Anyways I assume, you had explored all the options before adding
this as generic tools may not be able to pick this up. Instead, I would have
just stuck with vendor version in the standard protocol with build number
embedded into it. The date and other info must be implicit from the build.
I try to be more cautious and ask questions in the future as I don't want
vendor extensions to be dumping ground for really random things like this.
--
Regards,
Sudeep
Hi Sudeep,
On Wed, Jul 02, 2025 at 04:21:40PM +0100, Sudeep Holla wrote:
>On Fri, Jun 27, 2025 at 02:03:45PM +0800, Peng Fan wrote:
>> MISC protocol supports discovering the System Manager(SM) build
>> information including build commit, build time 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 | 35 ++++++++++++++++++++++
>> include/linux/scmi_imx_protocol.h | 12 ++++++++
>> 2 files changed, 47 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 a8915d3b4df518719d56bfff38922625ad9b70f6..1b24d070c6f4856b92f515fcdba5836fd6498ce6 100644
>> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
>> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
>> @@ -25,6 +25,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,
>
>I clearly missed to raise this point when the documentation for this command
>was added. Anyways I assume, you had explored all the options before adding
>this as generic tools may not be able to pick this up. Instead, I would have
>just stuck with vendor version in the standard protocol with build number
>embedded into it. The date and other info must be implicit from the build.
>
>I try to be more cautious and ask questions in the future as I don't want
>vendor extensions to be dumping ground for really random things like this.
+Souvik
And Loop our firmware owner to help comment. I just add what the firmware
supports here and allow linux to see the information when the firmware
does not have uart output in some builds.
From SCMI spec, it does not restrict what vendor extensions should be like
as I know. So I am not sure what we should do when we define vendor
extensions and what I should do next for this patch.
Please suggest.
Thanks,
Peng
>
>--
>Regards,
>Sudeep
On Fri, Jul 04, 2025 at 01:12:04PM +0800, Peng Fan wrote:
> Hi Sudeep,
>
> On Wed, Jul 02, 2025 at 04:21:40PM +0100, Sudeep Holla wrote:
> >On Fri, Jun 27, 2025 at 02:03:45PM +0800, Peng Fan wrote:
> >> MISC protocol supports discovering the System Manager(SM) build
> >> information including build commit, build time 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 | 35 ++++++++++++++++++++++
> >> include/linux/scmi_imx_protocol.h | 12 ++++++++
> >> 2 files changed, 47 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 a8915d3b4df518719d56bfff38922625ad9b70f6..1b24d070c6f4856b92f515fcdba5836fd6498ce6 100644
> >> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> >> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> >> @@ -25,6 +25,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,
> >
> >I clearly missed to raise this point when the documentation for this command
> >was added. Anyways I assume, you had explored all the options before adding
> >this as generic tools may not be able to pick this up. Instead, I would have
> >just stuck with vendor version in the standard protocol with build number
> >embedded into it. The date and other info must be implicit from the build.
> >
> >I try to be more cautious and ask questions in the future as I don't want
> >vendor extensions to be dumping ground for really random things like this.
>
> +Souvik
>
> And Loop our firmware owner to help comment. I just add what the firmware
> supports here and allow linux to see the information when the firmware
> does not have uart output in some builds.
>
> From SCMI spec, it does not restrict what vendor extensions should be like
> as I know. So I am not sure what we should do when we define vendor
> extensions and what I should do next for this patch.
>
Just to be clear, I am not against vendor extensions. I am just saying
this interface is not strictly needed. The vendor version could encode
this nicely and you could have a map. The only and main concern is having
such extensions will not help generic tools as these are very vendor specific.
It is good to have firmware version and other related details in a standard
format that anyone can understand without the need to dig deeper into vendor
specific extensions.
Again I am not saying to drop these interfaces, but you will get questioned
for its use in the kernel if that doesn't seem like the right approach.
--
Regards,
Sudeep
Hi Sudeep,
Sorry for late reply.
On Fri, Jul 04, 2025 at 09:59:16AM +0100, Sudeep Holla wrote:
>On Fri, Jul 04, 2025 at 01:12:04PM +0800, Peng Fan wrote:
>> Hi Sudeep,
>>
>> On Wed, Jul 02, 2025 at 04:21:40PM +0100, Sudeep Holla wrote:
>> >On Fri, Jun 27, 2025 at 02:03:45PM +0800, Peng Fan wrote:
>> >> MISC protocol supports discovering the System Manager(SM) build
>> >> information including build commit, build time 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 | 35 ++++++++++++++++++++++
>> >> include/linux/scmi_imx_protocol.h | 12 ++++++++
>> >> 2 files changed, 47 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 a8915d3b4df518719d56bfff38922625ad9b70f6..1b24d070c6f4856b92f515fcdba5836fd6498ce6 100644
>> >> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
>> >> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
>> >> @@ -25,6 +25,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,
>> >
>> >I clearly missed to raise this point when the documentation for this command
>> >was added. Anyways I assume, you had explored all the options before adding
>> >this as generic tools may not be able to pick this up. Instead, I would have
>> >just stuck with vendor version in the standard protocol with build number
>> >embedded into it. The date and other info must be implicit from the build.
>> >
>> >I try to be more cautious and ask questions in the future as I don't want
>> >vendor extensions to be dumping ground for really random things like this.
>>
>> +Souvik
>>
>> And Loop our firmware owner to help comment. I just add what the firmware
>> supports here and allow linux to see the information when the firmware
>> does not have uart output in some builds.
>>
>> From SCMI spec, it does not restrict what vendor extensions should be like
>> as I know. So I am not sure what we should do when we define vendor
>> extensions and what I should do next for this patch.
>>
>
>Just to be clear, I am not against vendor extensions. I am just saying
>this interface is not strictly needed. The vendor version could encode
>this nicely and you could have a map. The only and main concern is having
>such extensions will not help generic tools as these are very vendor specific.
>
>It is good to have firmware version and other related details in a standard
>format that anyone can understand without the need to dig deeper into vendor
>specific extensions.
>
>Again I am not saying to drop these interfaces, but you will get questioned
>for its use in the kernel if that doesn't seem like the right approach.
This is mostly for debug purpose to export the build information to linux,
such as firmware commit hash.
Should I still keep current patch, or do you have any suggestions
with current SM API? I think there is little chance to update SM to encode
vendor version to include build date, build num, and commit hash.
Thanks,
Peng
>
>--
>Regards,
>Sudeep
On Wed, Jul 09, 2025 at 12:10:06AM +0800, Peng Fan wrote:
> Hi Sudeep,
>
> Sorry for late reply.
> On Fri, Jul 04, 2025 at 09:59:16AM +0100, Sudeep Holla wrote:
> >On Fri, Jul 04, 2025 at 01:12:04PM +0800, Peng Fan wrote:
> >> Hi Sudeep,
> >>
> >> On Wed, Jul 02, 2025 at 04:21:40PM +0100, Sudeep Holla wrote:
> >> >On Fri, Jun 27, 2025 at 02:03:45PM +0800, Peng Fan wrote:
> >> >> MISC protocol supports discovering the System Manager(SM) build
> >> >> information including build commit, build time 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 | 35 ++++++++++++++++++++++
> >> >> include/linux/scmi_imx_protocol.h | 12 ++++++++
> >> >> 2 files changed, 47 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 a8915d3b4df518719d56bfff38922625ad9b70f6..1b24d070c6f4856b92f515fcdba5836fd6498ce6 100644
> >> >> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> >> >> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> >> >> @@ -25,6 +25,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,
> >> >
> >> >I clearly missed to raise this point when the documentation for this command
> >> >was added. Anyways I assume, you had explored all the options before adding
> >> >this as generic tools may not be able to pick this up. Instead, I would have
> >> >just stuck with vendor version in the standard protocol with build number
> >> >embedded into it. The date and other info must be implicit from the build.
> >> >
> >> >I try to be more cautious and ask questions in the future as I don't want
> >> >vendor extensions to be dumping ground for really random things like this.
> >>
> >> +Souvik
> >>
> >> And Loop our firmware owner to help comment. I just add what the firmware
> >> supports here and allow linux to see the information when the firmware
> >> does not have uart output in some builds.
> >>
> >> From SCMI spec, it does not restrict what vendor extensions should be like
> >> as I know. So I am not sure what we should do when we define vendor
> >> extensions and what I should do next for this patch.
> >>
> >
> >Just to be clear, I am not against vendor extensions. I am just saying
> >this interface is not strictly needed. The vendor version could encode
> >this nicely and you could have a map. The only and main concern is having
> >such extensions will not help generic tools as these are very vendor specific.
> >
> >It is good to have firmware version and other related details in a standard
> >format that anyone can understand without the need to dig deeper into vendor
> >specific extensions.
> >
> >Again I am not saying to drop these interfaces, but you will get questioned
> >for its use in the kernel if that doesn't seem like the right approach.
>
> This is mostly for debug purpose to export the build information to linux,
> such as firmware commit hash.
>
> Should I still keep current patch, or do you have any suggestions
> with current SM API? I think there is little chance to update SM to encode
> vendor version to include build date, build num, and commit hash.
>
I am against using this in the way you are doing in 7/7(i.e. exposing to
the userspace). Just dump the info on the serial port from the init code.
You don't need to expose it scmi_imx_misc_proto_ops as well.
--
Regards,
Sudeep
On Fri, Jun 27, 2025 at 02:03:45PM +0800, Peng Fan wrote:
> MISC protocol supports discovering the System Manager(SM) build
> information including build commit, build time and etc. Add the API
> for user to retrieve the information from SM.
>
Hi,
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> .../firmware/arm_scmi/vendors/imx/imx-sm-misc.c | 35 ++++++++++++++++++++++
> include/linux/scmi_imx_protocol.h | 12 ++++++++
> 2 files changed, 47 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 a8915d3b4df518719d56bfff38922625ad9b70f6..1b24d070c6f4856b92f515fcdba5836fd6498ce6 100644
> --- a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-misc.c
> @@ -25,6 +25,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_CTRL_NOTIFY = 0x8,
> };
>
> @@ -65,6 +66,13 @@ struct scmi_imx_misc_ctrl_get_out {
> __le32 val[];
> };
>
> +struct scmi_imx_misc_buildinfo_out {
> + __le32 buildnum;
> + __le32 buildcommit;
> + u8 builddate[MISC_MAX_BUILDDATE];
> + u8 buildtime[MISC_MAX_BUILDTIME];
> +};
> +
> static int scmi_imx_misc_attributes_get(const struct scmi_protocol_handle *ph,
> struct scmi_imx_misc_info *mi)
> {
> @@ -272,10 +280,37 @@ static int scmi_imx_misc_ctrl_set(const struct scmi_protocol_handle *ph,
> return ret;
> }
>
> +static int scmi_imx_discover_build_info(const struct scmi_protocol_handle *ph,
> + struct scmi_imx_misc_system_info *info)
> +{
> + struct scmi_imx_misc_buildinfo_out *out;
> + struct scmi_xfer *t;
> + int ret;
> +
> + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_MISC_DISCOVER_BUILDINFO, 0,
> + sizeof(*out), &t);
> + if (ret)
> + return ret;
> +
> + ret = ph->xops->do_xfer(ph, t);
> + if (!ret) {
> + out = t->rx.buf;
> + info->buildnum = le32_to_cpu(out->buildnum);
> + info->buildcommit = le32_to_cpu(out->buildcommit);
> + strscpy(info->date, out->builddate, MISC_MAX_BUILDDATE);
> + strscpy(info->time, out->buildtime, MISC_MAX_BUILDTIME);
> + }
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> static const struct scmi_imx_misc_proto_ops scmi_imx_misc_proto_ops = {
> .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,
> };
>
> 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 27bd372cbfb142b6acb0b1cf4b82f061529d0d45..826402dfe6f4d3b9e6d2e93868d6699f989e9bcc 100644
> --- a/include/linux/scmi_imx_protocol.h
> +++ b/include/linux/scmi_imx_protocol.h
> @@ -52,6 +52,16 @@ struct scmi_imx_misc_ctrl_notify_report {
> unsigned int flags;
> };
>
> +#define MISC_MAX_BUILDDATE 16
> +#define MISC_MAX_BUILDTIME 16
> +
> +struct scmi_imx_misc_system_info {
> + u32 buildnum;
> + u32 buildcommit;
> + u8 date[MISC_MAX_BUILDDATE];
> + u8 time[MISC_MAX_BUILDTIME];
> +};
> +
> struct scmi_imx_misc_proto_ops {
> int (*misc_ctrl_set)(const struct scmi_protocol_handle *ph, u32 id,
> u32 num, u32 *val);
> @@ -59,6 +69,8 @@ struct scmi_imx_misc_proto_ops {
> u32 *num, u32 *val);
> int (*misc_ctrl_req_notify)(const struct scmi_protocol_handle *ph,
> 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);
> };
LGTM.
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Thanks,
Cristian
© 2016 - 2025 Red Hat, Inc.