Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: 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, 18 Jul 2014 22:05:29 +0400	[thread overview]
Message-ID: <53C961E9.9000803@cogentembedded.com> (raw)
In-Reply-To: <53C8D2AE.3020300@imgtec.com>

Hello.

On 07/18/2014 11:54 AM, Jeffrey Deans wrote:

>>> From: Jeffrey Deans <jeffrey.deans@imgtec.com>

>>> The GICBIS macro could update the GIC registers incorrectly, depending
>>> on the data value passed in:

>>> * Bits were only OR'd into the register data, so register fields could
>>>    not be cleared.

>>> * Bits were OR'd into the register data without masking the data to the
>>>    correct field width, corrupting adjacent bits.

>>> Signed-off-by: Jeffrey Deans <jeffrey.deans@imgtec.com>
>>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>>> ---
>>>   arch/mips/include/asm/gic.h | 21 +++++++++++----------
>>>   1 file changed, 11 insertions(+), 10 deletions(-)

>>> diff --git a/arch/mips/include/asm/gic.h b/arch/mips/include/asm/gic.h
>>> index 8b30befd99d6..3f20b2111d56 100644
>>> --- a/arch/mips/include/asm/gic.h
>>> +++ b/arch/mips/include/asm/gic.h
>>> @@ -43,18 +43,17 @@
>>>   #ifdef GICISBYTELITTLEENDIAN
>>>   #define GICREAD(reg, data)    ((data) = (reg), (data) =
>>> le32_to_cpu(data))
>>>   #define GICWRITE(reg, data)    ((reg) = cpu_to_le32(data))
>>> -#define GICBIS(reg, bits)            \
>>> -    ({unsigned int data;            \
>>> -        GICREAD(reg, data);        \
>>> -        data |= bits;            \
>>> -        GICWRITE(reg, data);        \
>>> -    })
>>> -
>>>   #else
>>>   #define GICREAD(reg, data)    ((data) = (reg))
>>>   #define GICWRITE(reg, data)    ((reg) = (data))
>>> -#define GICBIS(reg, bits)    ((reg) |= (bits))
>>>   #endif
>>> +#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.

WBR, Sergei

  parent reply	other threads:[~2014-07-18 18:05 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 [this message]
2014-08-07 22:20         ` Ralf Baechle

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=53C961E9.9000803@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=jeffrey.deans@imgtec.com \
    --cc=linux-mips@linux-mips.org \
    --cc=markos.chandras@imgtec.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