linux-kernel - [PATCH v2 3/4] firmware: cs_dsp: Clarify wmfw format version log message

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: <20240710103640.78197-4-rf@opensource.cirrus.com>
Date: Wed, 10 Jul 2024 11:36:39 +0100
From: Richard Fitzgerald <rf@...nsource.cirrus.com>
To: <broonie@...nel.org>
CC: <linux-kernel@...r.kernel.org>, <patches@...nsource.cirrus.com>,
        <alsa-devel@...a-project.org>, <linux-sound@...r.kernel.org>
Subject: [PATCH v2 3/4] firmware: cs_dsp: Clarify wmfw format version log message

Change the log message of the wmfw format version to include
the file name, and change the message to say "format" instead
of "Firmware version". Merge this with the message that logs
the timestamp.

The wmfw format version is information that is useful to have
logged because the behaviour of firmware controls depends on
the wmfw format. So "unexpected" behaviour could be caused by
having expectations based on one format of wmfw when a
different format has been loaded.

But the original message was confusing. It reported the file
format version but didn't actually log the name of the file it
referred to. It also called it "Firmware version", which is
confusing when a later message also logs a firmware version
that is the version of the actual firmware within the wmfw.

The logging of the firmware timestamp has been merged into this.
That was originally a dbg-only message, but as we are already
logging a line of info, we might as well add a few extra
characters to log the timestamp. The timestamp is now logged
in hexadecimal - it's not particularly useful as a decimal
value.

Signed-off-by: Richard Fitzgerald <rf@...nsource.cirrus.com>
---
Changes since V1:
This is a completely different commit from the original V1 #3.
The V1 commit merged the wmfw format version message into the
INFO_TEXT message.
The V2 commit keeps the wmfw format in its own message but
clarifies the message, and merges it with a trivial message that
logged the header timestamp.
---
 drivers/firmware/cirrus/cs_dsp.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/cirrus/cs_dsp.c b/drivers/firmware/cirrus/cs_dsp.c
index 1bc2e0b6d40b..cce81a3f68f9 100644
--- a/drivers/firmware/cirrus/cs_dsp.c
+++ b/drivers/firmware/cirrus/cs_dsp.c
@@ -1502,7 +1502,6 @@ static int cs_dsp_load(struct cs_dsp *dsp, const struct firmware *firmware,
 		goto out_fw;
 	}

-	cs_dsp_info(dsp, "Firmware version: %d\n", header->ver);
 	dsp->fw_ver = header->ver;

 	if (header->core != dsp->type) {
@@ -1526,8 +1525,8 @@ static int cs_dsp_load(struct cs_dsp *dsp, const struct firmware *firmware,
 		goto out_fw;
 	}

-	cs_dsp_dbg(dsp, "%s: timestamp %llu\n", file,
-		   le64_to_cpu(footer->timestamp));
+	cs_dsp_info(dsp, "%s: format %d timestamp %#llx\n", file, header->ver,
+		    le64_to_cpu(footer->timestamp));

 	while (pos < firmware->size) {
 		/* Is there enough data for a complete block header? */
-- 
2.39.2