From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Arnd Bergmann <arnd@arndb.de>
Cc: dedekind1@gmail.com, dwmw2@infradead.org,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V4] mtd: Add DiskOnChip G3 support
Date: Tue, 27 Sep 2011 19:51:18 +0200 [thread overview]
Message-ID: <878vp96fhl.fsf@free.fr> (raw)
In-Reply-To: <201109271539.21533.arnd@arndb.de> (Arnd Bergmann's message of "Tue, 27 Sep 2011 15:39:21 +0200")
Arnd Bergmann <arnd@arndb.de> writes:
> On Thursday 22 September 2011, Robert Jarzmik wrote:
>> >> +#define doc_flashSequence(seq) \
>> >> +do { \
>> >> + doc_dbg("doc_flashSequence: %02x " #seq "\n", DoC_Seq_##seq); \
>> >> + doc_writeb(DoC_Seq_##seq, DoC_FlashSequence); \
>> >> +} while (0)
>> >> +
>> ...zip...
>> >
>> > Could you please turn these macros into 'static inline' function - this
>> > is one of the modern patterns of kernel programming - we try to use
>> > functions for better type checking.
>>
>> No sorry, that I cannot. If you look closely, the ##seq is not something you can
>> convert with an inline function, neither the #seq.
>
> Better not obfuscate the code like that then ;-)
>
> Really, passing the entire register name into an inline function is much
> preferred over string concatenation, because it lets you grep for where
> certain definitions are used.
Right. But how do handle the "#seq" then ?
The whole point here is to write humanly readable debug messages. A message of
the like "doc_flashsequence: 48 SET_PLANE1" is much better than
"doc_flashsequence: 48", don't you think ?
If we consider to loose that debugging messages, it's way easier to drop the "do
.. while(0)" sequences, and just keep the register write.
Now if you're convinced removing the "SET_PLANE1" debugging message is less
important that ability to grep the full register name, why not, but from a
maintenance point of view I would prefer letting the "macroness" in.
> You can also convert them to ALL_CAPS
> identifiers instead of cAmeLCAsE.
Point taken for V6.
>
> Finally, don't use the __raw_readb() style functions but instead use
> the regular readb() style, which is the correct one to use in device
> drivers.
Point taken for V6.
Cheers.
--
Robert
next prev parent reply other threads:[~2011-09-27 17:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-21 19:27 [PATCH V4] mtd: Add DiskOnChip G3 support Robert Jarzmik
2011-09-22 14:45 ` Artem Bityutskiy
2011-09-22 17:42 ` Robert Jarzmik
2011-09-27 13:39 ` Arnd Bergmann
2011-09-27 17:51 ` Robert Jarzmik [this message]
2011-09-28 12:45 ` Arnd Bergmann
2011-10-01 12:19 ` Robert Jarzmik
2011-10-01 15:02 ` Arnd Bergmann
2011-09-23 19:14 ` [PATCH V5] " Robert Jarzmik
2011-09-27 12:58 ` Artem Bityutskiy
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=878vp96fhl.fsf@free.fr \
--to=robert.jarzmik@free.fr \
--cc=arnd@arndb.de \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@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