Re: OMAP3 CPU Info has weird output in 4.9-RC1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 25.10.2016 01:53, Tony Lindgren wrote:
* Adam Ford <aford173@xxxxxxxxx> [161021 08:47]:
The  omap3_cpufinfo function with the macro OMAP3_SHOW_FEATURE seems
to be adding extra newlines for some reason that it's obvious to me.

Instead of printing:
[    0.000000] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )

Kernel 4.9-RC1 is adding newlines.

[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] OMAP3630 ES1.2 (
[    0.000000] l2cache
[    0.000000] iva
[    0.000000] sgx
[    0.000000] neon
[    0.000000] isp
[    0.000000] 192mhz_clk
[    0.000000] )

Has anyone else seen this?  I looked at the macro, and I looked at the
function, and nothing stood out to me.

I think it's because of the printk cleanups now merged. Let's also
fix the empty space there while at it, patch below.

Regards,

Tony

8< -----------------------
From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@xxxxxxxxxxx>
Date: Mon, 24 Oct 2016 15:47:00 -0700
Subject: [PATCH] ARM: OMAP3: Fix formatting of features printed

With the printk cleanups merged into v4.9-rc1, we now get the omap
revision printed on multiple lines. Let's fix that and also remove the
extra empty space at the end of the features.

Reported-by: Adam Ford <aford173@xxxxxxxxx>
Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
---
 arch/arm/mach-omap2/id.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -205,11 +205,15 @@ void __init omap2xxx_check_revision(void)

 #define OMAP3_SHOW_FEATURE(feat)		\
 	if (omap3_has_ ##feat())		\
-		printk(#feat" ");
+		bufp += sprintf(bufp, #feat" ");

 static void __init omap3_cpuinfo(void)
 {
 	const char *cpu_name;
+	char buf[64];

Are we sure 64 bytes are enough for everybody :) ?

I guess something like:

#define OMAP3_SHOW_FEATURE(feat)		\
	if (omap3_has_ ##feat()) {		\
		int __chars = scnprintf(bufp, sizeof(buf) - (bufp - buf), #feat" "); \
		WARN_ONCE(__chars != (strlen(#feat" "))); \
		bufp += __chars;
	}

will do a better job in the future. The similar needs to be done for the rest of the sprintfs. Otherwise we risk stack corruption if some fancy omap3 appear out of the blue, iiuc.

I didn't even compile-test the above, but I am sure you get the idea.

+	char *bufp = buf;
+
+	memset(buf, 0, sizeof(buf));

 	/*
 	 * OMAP3430 and OMAP3530 are assumed to be same.
@@ -244,7 +248,7 @@ static void __init omap3_cpuinfo(void)
 	sprintf(soc_name, "%s", cpu_name);

 	/* Print verbose information */
-	pr_info("%s %s (", soc_name, soc_rev);
+	bufp += sprintf(bufp, "%s %s (", soc_name, soc_rev);

 	OMAP3_SHOW_FEATURE(l2cache);
 	OMAP3_SHOW_FEATURE(iva);
@@ -252,8 +256,10 @@ static void __init omap3_cpuinfo(void)
 	OMAP3_SHOW_FEATURE(neon);
 	OMAP3_SHOW_FEATURE(isp);
 	OMAP3_SHOW_FEATURE(192mhz_clk);
-
-	printk(")\n");
+	if (*(bufp - 1) == ' ')
+		bufp--;
+	bufp += sprintf(bufp, ")\n");
+	pr_info("%s", buf);
 }

 #define OMAP3_CHECK_FEATURE(status,feat)				\


Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux