From: Kevin Hilman <khilman@ti.com>
To: Vladimir Zapolskiy <vzapolskiy@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>,
Benoit Cousson <b-cousson@ti.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv2 0/2] [RFC] Shrink clock data utilizing preprocessor
Date: Tue, 17 May 2011 15:06:43 +0200 [thread overview]
Message-ID: <87r57x4gt8.fsf@ti.com> (raw)
In-Reply-To: <1305495958-2236-1-git-send-email-vzapolskiy@gmail.com> (Vladimir Zapolskiy's message of "Mon, 16 May 2011 00:45:56 +0300")
Vladimir Zapolskiy <vzapolskiy@gmail.com> writes:
> This change shows a possibility to utilize C preprocessor to remove
> redundant data from clock definitions for OMAP4 architecture.
>
> If the change is evaluated as a positive one, the same approach could
> be applied in reducing LOCs from other files, which contain monotonous
> data enumeration.
Now that I can apply these patches and look at the result, I still have
the same opinion. For me, this results in a major loss of readability.
Changes just to make nice diffstats are fine, but not when it impacts
readability, etc. Especially since this data will likely be eventually
moved to device tree, I'd rather see consolidation efforts focused
elsewhere.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 0/2] [RFC] Shrink clock data utilizing preprocessor
Date: Tue, 17 May 2011 15:06:43 +0200 [thread overview]
Message-ID: <87r57x4gt8.fsf@ti.com> (raw)
In-Reply-To: <1305495958-2236-1-git-send-email-vzapolskiy@gmail.com> (Vladimir Zapolskiy's message of "Mon, 16 May 2011 00:45:56 +0300")
Vladimir Zapolskiy <vzapolskiy@gmail.com> writes:
> This change shows a possibility to utilize C preprocessor to remove
> redundant data from clock definitions for OMAP4 architecture.
>
> If the change is evaluated as a positive one, the same approach could
> be applied in reducing LOCs from other files, which contain monotonous
> data enumeration.
Now that I can apply these patches and look at the result, I still have
the same opinion. For me, this results in a major loss of readability.
Changes just to make nice diffstats are fine, but not when it impacts
readability, etc. Especially since this data will likely be eventually
moved to device tree, I'd rather see consolidation efforts focused
elsewhere.
Kevin
next prev parent reply other threads:[~2011-05-17 13:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-15 21:45 [PATCHv2 0/2] [RFC] Shrink clock data utilizing preprocessor Vladimir Zapolskiy
2011-05-15 21:45 ` Vladimir Zapolskiy
2011-05-15 21:45 ` [PATCHv2 1/2] [RFC] OMAP4: clock data: shrink " Vladimir Zapolskiy
2011-05-15 21:45 ` Vladimir Zapolskiy
2011-05-15 21:45 ` [PATCHv2 2/2] [RFC] OMAP4: clock data: shrink more clock data Vladimir Zapolskiy
2011-05-15 21:45 ` Vladimir Zapolskiy
2011-05-16 6:53 ` Avinash.H.M.
2011-05-16 6:53 ` Avinash.H.M.
2011-05-16 7:56 ` [PATCHv2 0/2] [RFC] Shrink clock data utilizing preprocessor Sascha Hauer
2011-05-16 7:56 ` Sascha Hauer
2011-05-16 16:25 ` Vladimir Zapolskiy
2011-05-16 16:25 ` Vladimir Zapolskiy
2011-05-17 13:06 ` Kevin Hilman [this message]
2011-05-17 13:06 ` Kevin Hilman
2011-05-17 15:47 ` Premi, Sanjeev
2011-05-17 15:47 ` Premi, Sanjeev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r57x4gt8.fsf@ti.com \
--to=khilman@ti.com \
--cc=b-cousson@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
--cc=vzapolskiy@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.