public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
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

  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