From: Arnd Bergmann <arnd@arndb.de>
To: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
'Greg KH' <greg@kroah.com>
Subject: Re: [PATCH 09/12] unicore32 machine related files: hardware registers
Date: Thu, 17 Feb 2011 17:59:45 +0100 [thread overview]
Message-ID: <201102171759.45365.arnd@arndb.de> (raw)
In-Reply-To: <015301cbcdae$55cdb7e0$016927a0$@mprc.pku.edu.cn>
On Wednesday 16 February 2011, Guan Xuetao wrote:
> +#define io_p2v(x) ((x) - PKUNITY_IOSPACE_BASE)
> +#define io_v2p(x) ((x) + PKUNITY_IOSPACE_BASE)
> +
> +#ifndef __ASSEMBLY__
> +
> +# define __REG(x) (*((volatile unsigned long *)io_p2v(x)))
> +# define __PREG(x) (io_v2p((unsigned long)&(x)))
> +
> +#else
> +
> +# define __REG(x) io_p2v(x)
> +# define __PREG(x) io_v2p(x)
> #define PKUNITY_IOSPACE_BASE 0x80000000 /* 0x80000000 - 0xFFFFFFFF 2GB */
The typecasts look wrong here:
- "volatile unsigned long*" is not the right pointer type to do I/O on. It
should instead be "void __iomem *". Please use the "sparse" tool with "make C=1"
to get warnings about incorrect pointer type accesses.
- PKUNITY_IOSPACE_BASE seems to be both a virtual and a physical address, which
is a bad idea, because it prevents a lot of the checks from working correctly.
- The __REG/__PREG macros seem to have the same purpose as io_p2v/io_v2p, you
should not require both.
- The term IOSPACE is confusing, because it normally refers to the PCI PIO
space, while you mean the SoC's MMIO region
I would recommend defining these as
#ifndef __ASSEMBLY__
#define PKUNITY_MMIO_VIRT ((void __iomem *)0x80000000)
#else
#define PKUNITY_MMIO_VIRT 0x80000000
#endif
#define io_p2v(x) ((x) - PKUNITY_MMIO_VIRT)
#define io_v2p(x) ((x) + PKUNITY_MMIO_VIRT)
/* please remove the two macros below as soon as all users are changed to use io_p2v */
#define __REG(x) io_p2v(x)
#define __PREG(x) io_v2p(x)
Arnd
next prev parent reply other threads:[~2011-02-17 17:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-16 7:51 [PATCH 09/12] unicore32 machine related files: hardware registers Guan Xuetao
2011-02-17 16:59 ` Arnd Bergmann [this message]
2011-02-18 9:52 ` Guan Xuetao
2011-02-18 10:42 ` Arnd Bergmann
2011-02-22 14:09 ` Guan Xuetao
2011-02-22 14:19 ` Arnd Bergmann
2011-02-22 14:19 ` Arnd Bergmann
2011-02-26 12:23 ` Guan Xuetao
2011-02-26 13:16 ` Arnd Bergmann
2011-02-27 3:35 ` Guan Xuetao
2011-02-27 17:15 ` Arnd Bergmann
2011-02-27 17:15 ` Arnd Bergmann
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=201102171759.45365.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=greg@kroah.com \
--cc=gxt@mprc.pku.edu.cn \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@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