From: dwalker@codeaurora.org (Daniel Walker)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] serial: DCC(JTAG) serial and console emulation support
Date: Wed, 06 Oct 2010 07:49:41 -0700 [thread overview]
Message-ID: <1286376581.22265.85.camel@m0nster> (raw)
In-Reply-To: <alpine.LFD.2.00.1010061016280.3107@xanadu.home>
On Wed, 2010-10-06 at 10:22 -0400, Nicolas Pitre wrote:
> On Wed, 6 Oct 2010, Daniel Walker wrote:
>
> > On Tue, 2010-10-05 at 22:55 -0400, Nicolas Pitre wrote:
> > > On Tue, 5 Oct 2010, Daniel Walker wrote:
> > >
> > > > +#if !defined(CONFIG_CPU_V7)
> > > > +static inline char
> > > > +__dcc_getchar(void)
> > > > +{
> > > > + char __c;
> > > > +
> > > > + asm("mrc p14, 0, %0, c0, c5, 0 @ read comms data reg"
> > > > + : "=r" (__c) : : "cc");
> > > > +
> > > > + return __c;
> > > > +}
> > > > +#else
> > > > +static inline char
> > > > +__dcc_getchar(void)
> > > > +{
> > > > + char __c;
> > > > +
> > > > + asm(
> > > > + "get_wait: mrc p14, 0, pc, c0, c1, 0 \n\
> > > > + bne get_wait \n\
> > > > + mrc p14, 0, %0, c0, c5, 0 @ read comms data reg"
> > > > + : "=r" (__c) : : "cc");
> > > > +
> > > > + return __c;
> > > > +}
> > > > +#endif
> > > > +
> > > > +#if !defined(CONFIG_CPU_V7)
> > > > +static inline void
> > > > +__dcc_putchar(char c)
> > > > +{
> > > > + asm("mcr p14, 0, %0, c0, c5, 0 @ write a char"
> > > > + : /* no output register */
> > > > + : "r" (c) : "cc");
> > > > +}
> > > > +#else
> > > > +static inline void
> > > > +__dcc_putchar(char c)
> > > > +{
> > > > + asm(
> > > > + "put_wait: mrc p14, 0, pc, c0, c1, 0 \n\
> > > > + bcs put_wait \n\
> > > > + mcr p14, 0, %0, c0, c5, 0 "
> > > > + : : "r" (c) : "cc");
> > > > +}
> > > > +#endif
> > >
> > > Please move the #ifdef conditionals inside the respective functions so
> > > to have only one function pair with the various alternatives embedded
> > > into them.
> >
> > My typical clean up policy is do to the inverse of what your suggesting.
> > Mainly because that's the method that I see used extensive in generic
> > parts of the kernel.
>
> Do you have an example? I don't see such thing in generic code, unless
> two versions of the same function are totally different. In this case
> you have only the inner inline asm code that is different.
These may not be the best examples but in include/linux/workqueue.h line
150, work_static() for instance if fully inside an ifdef. There is one
other function example in that file, an one macro version. Also some in
include/linux/ftrace.h , but in that case either the functions do
something or nothing. ftrace.h is a little bit confsued, it has example
of it your way and my way.
It doesn't appear to be a constant .. I see it your way and my way.
> > From my perspective there are pluses an minuses to both. Your method
> > reduces lines, and duplication. My method makes the code easier to read.
>
> I disagree. In reviewing your patch I had to go back and forth between
> the different versions just to figure out what was actually different to
> justify this #ifdef in the first place. If the #ifdef..#endif was
> surrounding only the different inline asm statements then the difference
> would have been more obvious.
You would have had to go back and forth either way , wouldn't you? In
this case the functions are actually totally different.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
next prev parent reply other threads:[~2010-10-06 14:49 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-05 19:07 [PATCH] serial: DCC(JTAG) serial and console emulation support Daniel Walker
2010-10-06 2:55 ` Nicolas Pitre
2010-10-06 13:48 ` Daniel Walker
2010-10-06 14:22 ` Nicolas Pitre
2010-10-06 14:49 ` Daniel Walker [this message]
2010-10-06 15:21 ` Nicolas Pitre
2010-10-06 15:33 ` Daniel Walker
2010-10-06 15:47 ` Nicolas Pitre
2010-10-06 15:54 ` Daniel Walker
2010-10-06 16:22 ` Nicolas Pitre
2010-10-06 16:40 ` Daniel Walker
2010-10-06 17:02 ` Nicolas Pitre
2010-10-06 17:07 ` Daniel Walker
2010-10-07 21:27 ` Tony Lindgren
2010-10-07 21:58 ` Daniel Walker
2010-10-08 1:28 ` Nicolas Pitre
2010-10-08 20:35 ` Tony Lindgren
2010-10-08 20:59 ` Tony Lindgren
2010-10-08 21:27 ` Nicolas Pitre
2010-10-08 20:36 ` Tony Lindgren
2010-10-08 1:25 ` Nicolas Pitre
2010-10-08 20:32 ` Tony Lindgren
2010-10-08 20:58 ` Tony Lindgren
2010-10-08 21:28 ` Nicolas Pitre
2010-10-08 21:25 ` Nicolas Pitre
2010-10-08 21:49 ` Tony Lindgren
2010-10-09 0:57 ` Nicolas Pitre
2010-10-13 15:21 ` Arnd Bergmann
2010-10-13 16:17 ` Daniel Walker
2010-10-13 17:44 ` Arnd Bergmann
2010-10-13 18:08 ` Daniel Walker
2010-10-13 19:45 ` Arnd Bergmann
2010-10-13 19:52 ` Daniel Walker
2010-10-13 20:10 ` Arnd Bergmann
2010-10-13 20:24 ` Daniel Walker
2010-10-13 20:44 ` Nicolas Pitre
2010-10-13 20:49 ` Daniel Walker
2010-10-13 22:51 ` Nicolas Pitre
2010-10-13 23:26 ` Russell King - ARM Linux
2010-10-13 23:41 ` Nicolas Pitre
2010-10-13 19:55 ` Nicolas Pitre
2010-10-13 20:00 ` Daniel Walker
2010-10-13 20:27 ` Nicolas Pitre
2010-10-13 20:47 ` Daniel Walker
2010-10-13 22:05 ` Daniel Walker
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=1286376581.22265.85.camel@m0nster \
--to=dwalker@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).