Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Kyle McMartin <kyle@mcmartin.ca>
Cc: linux-parisc@vger.kernel.org
Subject: Re: parisc: add barriers to mmio accessors
Date: Tue, 3 Jun 2008 06:42:29 -0600	[thread overview]
Message-ID: <20080603124229.GA8434@parisc-linux.org> (raw)
In-Reply-To: <20080603054212.GA31771@phobos.i.cabal.ca>

On Tue, Jun 03, 2008 at 01:42:12AM -0400, Kyle McMartin wrote:
> +#ifdef CONFIG_64BIT
> +	asm volatile(
> +	"	ldq	0(%0), %1\n"
> +	: : "r"(addr), "r"(q) : "memory");
> +#else
> +	unsigned int q_lo, q_hi;
> +	q_hi = __raw_readl(addr);
> +	q_lo = __raw_readl(addr+4);
> +	q = (unsigned long long)(q_hi << 32) | (q_lo);
> +#endif

Are you sure this is correct?  Seems to me it should be:

	q = ((unsigned long long)q_hi << 32) | q_lo;

I would have thought GCC would complain about a shift exceeding the
width of the type.

> +static inline void __raw_writeq(unsigned long long q, volatile void __iomem *addr)
>  {
> -	*(volatile unsigned long long __force *) addr = b;
> +#ifdef CONFIG_64BIT
> +	asm volatile(
> +	"	stq	%1, 0(%0)\n"
> +	: : "r"(addr), "r"(q) : "memory");
> +#else
> +	unsigned int q_hi = (q >> 32) & ~0UL;
> +	unsigned int q_lo = (q) & ~0UL;
> +	__raw_writel(q_hi, addr);
> +	__raw_writel(q_lo, addr+4);
> +#endif

It feels a little funny to be masking with UL when assigning to an
unsigned int.  I'd personally use 0xffffffff or ~0U or nothing at all
since it'll be truncated anyway.  (I recognise the value of saying "I do
intend to truncate this value" explicitly though.)

A third thing is that you're doing this to the __raw_ variants which
don't have to be serialised.  How about we keep the current definitions of
__raw_readX/__raw_writeX, define the regular readX/writeX to be the inline
assembler you've just posted, and add new defines of __readX/__writeX
as byteswapping versions of __raw_readX/__raw_writeX?

[For those who aren't on linux-arch, there's just been a long thread
about the semantics of the different accessors and the above reflects my
understanding of that thread.]

Should we add memory clobbers to gsc_readX/gsc_writeX?

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  parent reply	other threads:[~2008-06-03 12:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-03  5:42 parisc: add barriers to mmio accessors Kyle McMartin
2008-06-03 12:22 ` Carlos O'Donell
2008-06-03 12:23   ` Carlos O'Donell
2008-06-03 12:42 ` Matthew Wilcox [this message]
2008-06-03 14:29   ` Kyle McMartin

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=20080603124229.GA8434@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=kyle@mcmartin.ca \
    --cc=linux-parisc@vger.kernel.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