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."
next prev 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