From: jassisinghbrar@gmail.com (jassi brar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/7] PL330: Add common core driver\
Date: Sun, 2 May 2010 09:23:39 +0900 [thread overview]
Message-ID: <p2u1b68c6791005011723g595c30abqe7236b3c4b4f07d9@mail.gmail.com> (raw)
In-Reply-To: <j2he9c3a7c21005011401l7935e674k7a2cf67dfe51b165@mail.gmail.com>
On Sun, May 2, 2010 at 6:01 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Mon, Apr 26, 2010 at 12:09 AM, Ben Dooks <ben-linux@fluff.org> wrote:
>> On Mon, Apr 26, 2010 at 03:20:59PM +0900, jassi brar wrote:
>>> On Mon, Apr 26, 2010 at 1:54 PM, Ben Dooks <ben-linux@fluff.org> wrote:
>>> > On Wed, Apr 21, 2010 at 04:27:28PM +0900, jassisinghbrar at gmail.com wrote:
>>> >> From: Jassi Brar <jassi.brar@samsung.com>
>>> >> + * Mark a _pl330_req as free.
>>> >> + * We do it by writing DMAEND as the first instruction
>>> >> + * because no valid request is going to have DMAEND as
>>> >> + * its first instruction to execute.
>>> >> + */
>>> >> +#define MARK_FREE(req) ? ? ? do { \
>>> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? _emit_END(0, (req)->mc_cpu); \
>>> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? (req)->mc_len = 0; \
>>> >> + ? ? ? ? ? ? ? ? ? ? } while (0)
>>> >
>>> > I think inline functions for these would be easier to read.
>>> you mean alignment that we see here? it's actually correctly
>>> aligned in an editor.
>>
>> firstly, on the grounds it avoids the whole \
>> and secondly on the grounds inline functions get checked by the compiler
>> whether they're used or not.
>
> ...thirdly any macro that evaluates its arguments more than once is
> potentially dangerous for cases like MARK_FREE(req++).
>
>>
>> I belive any macro over a couple of lines is probably doing too much
>> work.
Well, the three points are valid and we might have even more against
using macros _generally_. But just for the sake of clarification/learning..
a) We do have many multi-line macros in the kernel
b) The macro MARK_FREE does two independent things, where as a
function usually does a sequence of logical steps. The macro
MARK_FREE is clearly being used in our case.
c) Since the driver uses exactly two requests and we always explicitly
free req[0] or req[1], I think we are in no danger of referencing invalid
memory here.
Though having been asked by two maintainers, I will change it to
inline func though.
Thanks.
prev parent reply other threads:[~2010-05-02 0:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-21 7:27 [PATCH 1/7] PL330: Add common core driver jassisinghbrar at gmail.com
2010-04-23 21:49 ` Linus Walleij
2010-04-23 23:20 ` jassi brar
2010-04-25 1:59 ` Linus Walleij
2010-04-26 4:56 ` Ben Dooks
2010-04-26 6:41 ` jassi brar
2010-04-26 4:54 ` Ben Dooks
2010-04-26 6:20 ` jassi brar
2010-04-26 7:09 ` [PATCH 1/7] PL330: Add common core driver\ Ben Dooks
2010-05-01 21:01 ` Dan Williams
2010-05-02 0:23 ` jassi brar [this message]
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=p2u1b68c6791005011723g595c30abqe7236b3c4b4f07d9@mail.gmail.com \
--to=jassisinghbrar@gmail.com \
--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).