[Top] [All Lists]

Re: [PATCH] MIPS: Rewrite cpu_to_name so it has one statement per line.

To: David Daney <>
Subject: Re: [PATCH] MIPS: Rewrite cpu_to_name so it has one statement per line.
From: David VomLehn <>
Date: Tue, 14 Oct 2008 11:25:19 -0700
Authentication-results: sj-dkim-2;; dkim=pass ( sig from verified; );
Cc: Ralf Baechle <>,, "Paoletti, Tomaso" <>
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=2727; t=1224008736; x=1224872736; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20David=20VomLehn=20<> |Subject:=20Re=3A=20[PATCH]=20MIPS=3A=20Rewrite=20cpu_to_na me=20so=20it=20has=20one=20statement=20per=0A=20line. |Sender:=20; bh=Hy6bNr9oItqRkK2yZ1YoS3Oom3uVDqJ3dC8Oo2Jl6Lc=; b=eQhx2fw3hA5onwAHASSWmoxRAB74qdYDFxZva0xegHAfu8mGFkOShALk7c I8bnBoiWx/0sSEPKxbqIIu4+PZFFLz7CuPZ7jwsvjfJmTOShjAK33J3BnZIQ osFU6FfkQK;
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
User-agent: Thunderbird (Windows/20080708)
David Daney wrote:
Ralf Baechle wrote:
On Mon, Oct 13, 2008 at 11:00:30AM -0700, David Daney wrote:

Rewrite cpu_to_name so it has one statement per line.

Future changes can now pass

It's been one of those changes where I found the Linux coding style in my
opinion at least, not to be optimal. My plan was to rewrite it like below
incomplete patch for ages.  What do you think?


Signed-off-by: Ralf Baechle <>

diff --git a/arch/mips/include/asm/cpu-info.h b/arch/mips/include/asm/cpu-info.h
index 744cd8f..6d0f891 100644
--- a/arch/mips/include/asm/cpu-info.h
+++ b/arch/mips/include/asm/cpu-info.h
@@ -75,6 +75,7 @@ struct cpuinfo_mips {
     unsigned int        watch_reg_use_cnt; /* Usable by ptrace */
 #define NUM_WATCH_REGS 4
     u16            watch_reg_masks[NUM_WATCH_REGS];
+    const char        *name;
 } __attribute__((aligned(SMP_CACHE_BYTES)));

It increases the size of the cpuinfo_mips structure by sizeof(char *)
for data that is only ever used in /proc/cpuinfo, also it goes against
my sense of data normalization.  So I think the current method of
looking it up on demand is fine.

I am not enamored with my patch as it doubles the number of lines in
the function.  So we will defer to you and follow which ever style you
decide is best.

David Daney

This is a pretty trivial issue, but I would note that the /proc/cpuinfo code is not a performance critical path. Thus, adding redundant data isn't worth it. If we really care about checkpatch and, even in this case, I kinda do, we could shrink the code by doing a linear scan of a table that contains the CPU type and the name. If you really care about code and data size *and* want it fast you could demand that the CPU types be sequentially numbered values, possibly enums, that you use to index into a table of CPU names.

Okay, I'm done beating this dead horse...

David VomLehn

- - - - - Cisco - - - - - This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.

<Prev in Thread] Current Thread [Next in Thread>