linux-kernel - Re: [PATCH 2/7] firmware: arm_scmi: imx: Support discovering buildinfo of MISC protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250708161006.GA13177@nxa18884-linux>
Date: Wed, 9 Jul 2025 00:10:06 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Chuck Cannon <chuck.cannon@....com>,
	Souvik Chakravarty <souvik.chakravarty@....com>,
	Peng Fan <peng.fan@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>, arm-scmi@...r.kernel.org,
	imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] firmware: arm_scmi: imx: Support discovering
 buildinfo of MISC protocol

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@....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