Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Jeffrey Deans <jeffrey.deans@imgtec.com>,
	Markos Chandras <markos.chandras@imgtec.com>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH 7/7] MIPS: GIC: Fix GICBIS macro
Date: Fri, 8 Aug 2014 00:20:38 +0200	[thread overview]
Message-ID: <20140807222038.GF29898@linux-mips.org> (raw)
In-Reply-To: <53C961E9.9000803@cogentembedded.com>

On Fri, Jul 18, 2014 at 10:05:29PM +0400, Sergei Shtylyov wrote:

> >>>+#define GICBIS(reg, mask, bits)            \
> >>>+    do { u32 data;                \
> >>>+        GICREAD((reg), data);        \
> 
> >>    Why () only around 'reg', not around 'data'?
> 
> >Brackets aren't necessary around "data" because it is declared at the start of
> >the "do" code block, so it can't expand to anything else within that scope.
> 
>    Oh, I was not attentive enough, sorry about that... :-<
>    However, it makes sense to at least put that declaration at a separate line.

And it's not safe against multiple evaluation of macro arguments.  Imagine
what's going to happen if GICBIS is called as something like

	GICBIS(++a, ++b, c);

That'll expand to:

    do { u32 data;
            GICREAD((++a), data);
            data &= ~(++b);
            data |= ((bits) & (++b));
            GICWRITE((++a), data);
    } while (0)

Paranoia?

  Ralf

      reply	other threads:[~2014-08-07 22:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17  8:20 [PATCH 0/7] Misc GIC fixes Markos Chandras
2014-07-17  8:20 ` Markos Chandras
2014-07-17  8:20 ` [PATCH 1/7] MIPS: GIC: move GIC interrupt bitmap declarations Markos Chandras
2014-07-17  8:20   ` Markos Chandras
2014-07-17  8:20 ` [PATCH 2/7] MIPS: GIC: Move GIC_NUM_INTRS into platform irq.h Markos Chandras
2014-07-17  8:20   ` Markos Chandras
2014-07-17  8:20 ` [PATCH 3/7] MIPS: GIC: Remove GIC_FLAG_IPI Markos Chandras
2014-07-17  8:20   ` Markos Chandras
2014-07-17  8:20 ` [PATCH 4/7] MIPS: GIC: Prevent array overrun Markos Chandras
2014-07-17  8:20   ` Markos Chandras
2014-07-17  8:20 ` [PATCH 5/7] MIPS: GIC: Generalise check for pending interrupts Markos Chandras
2014-07-17  8:20   ` Markos Chandras
2014-07-17  8:20 ` [PATCH 6/7] MIPS: Malta: Fix dispatching of GIC interrupts Markos Chandras
2014-07-17  8:20   ` Markos Chandras
2014-08-04 22:57   ` Florian Fainelli
2014-07-17  8:20 ` [PATCH 7/7] MIPS: GIC: Fix GICBIS macro Markos Chandras
2014-07-17  8:20   ` Markos Chandras
2014-07-17 12:47   ` Sergei Shtylyov
2014-07-18  7:54     ` Jeffrey Deans
2014-07-18  7:54       ` Jeffrey Deans
2014-07-18 10:05       ` Markos Chandras
2014-07-18 10:05         ` Markos Chandras
2014-07-18 18:05       ` Sergei Shtylyov
2014-08-07 22:20         ` Ralf Baechle [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=20140807222038.GF29898@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=jeffrey.deans@imgtec.com \
    --cc=linux-mips@linux-mips.org \
    --cc=markos.chandras@imgtec.com \
    --cc=sergei.shtylyov@cogentembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox