public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Rik van Riel <riel@redhat.com>,
	linux-kernel@vger.kernel.org, ajackson@redhat.com,
	airlied@redhat.com, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH 2/3] powerpc ioremap_prot
Date: Wed, 30 Apr 2008 08:07:53 +1000	[thread overview]
Message-ID: <1209506873.18023.197.camel@pasglop> (raw)
In-Reply-To: <20080429111734.b4bc93fc.akpm@linux-foundation.org>


On Tue, 2008-04-29 at 11:17 -0700, Andrew Morton wrote:
> 
> Given that x86 implements ioremap_prot() as a regular C function, it
> would
> be nicer to require that all architectures do that.  Especially as
> macros
> suck.
> 
> Your powerpc implementation of ioremap_prot() has a different
> signature
> from the x86 one: `phys_addr_t address' versus `resource_size_t
> phys_addr'.
> Can that be improved?

Well, we already had ioremap_flags() which is the same thing, that's why
I made it just a #define :-)

But I'm pondering removing our ioremap_flags completely in favor of
ioremap_prot. This was just a patch to "make it work" so Rik could move
on with his core patch (btw. Rik, you got the SOBs in the wrong order on
that one).

Regarding the difference, well, it has to do with us historically using
that phys_addr_t type for ioremap. I can try to look into changing that
but it will take a bit more effort.

> >  static inline pte_t pte_mkspecial(pte_t pte) {
> >       return pte; }
> > +static inline unsigned long pte_pgprot(pte_t pte) {
> > +     return __pgprot(pte_val(pte)) & PAGE_PROT_BITS; }
> 
> ick.  \n's are cheap.

Yeah well, just adapted to the style of the other ones around it :-)

Those things have been there forever, I think we can even blame
pre-paulus maintainership here !

I'll change them all in one go in a different patch if you want.

> > +static inline unsigned long pte_pgprot(pte_t pte) {
> > +     return __pgprot(pte_val(pte)) & PAGE_PROT_BITS; }

Ben.



  reply	other threads:[~2008-04-29 22:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29 15:33 [PATCH 2/3] powerpc ioremap_prot Rik van Riel
2008-04-29 18:17 ` Andrew Morton
2008-04-29 22:07   ` Benjamin Herrenschmidt [this message]
2008-04-29 22:36     ` Andrew Morton

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=1209506873.18023.197.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=airlied@redhat.com \
    --cc=ajackson@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=riel@redhat.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