From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: linuxppc-dev@ozlabs.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, adaplas@gmail.com
Subject: Re: [PATCH 3/3] atyfb: Fix 64 bits resources on 32 bits archs
Date: Wed, 23 Apr 2008 08:20:06 +1000 [thread overview]
Message-ID: <1208902806.9640.136.camel@pasglop> (raw)
In-Reply-To: <480E07BC.3050107@ru.mvista.com>
On Tue, 2008-04-22 at 19:43 +0400, Sergei Shtylyov wrote:
> Not sure what that change gives us -- this function mostly treats 'addr'
> as unsigned long (casting it to char/void *), ot compares it to 'unsigned
> long' 'base' variable -- which should be made 'resource_size_t' in its turn
> being assigned resource's start value. So, this part of patch looks incomplete
> (and yet I'm not sure if SPARC really needs all that)...
I just wanted to make sure both setup functions has the same prototype.
I think sparc doesn't need fixing in there.
Ben.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: linuxppc-dev@ozlabs.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, adaplas@gmail.com
Subject: Re: [PATCH 3/3] atyfb: Fix 64 bits resources on 32 bits archs
Date: Wed, 23 Apr 2008 08:20:06 +1000 [thread overview]
Message-ID: <1208902806.9640.136.camel@pasglop> (raw)
In-Reply-To: <480E07BC.3050107@ru.mvista.com>
On Tue, 2008-04-22 at 19:43 +0400, Sergei Shtylyov wrote:
> Not sure what that change gives us -- this function mostly treats 'addr'
> as unsigned long (casting it to char/void *), ot compares it to 'unsigned
> long' 'base' variable -- which should be made 'resource_size_t' in its turn
> being assigned resource's start value. So, this part of patch looks incomplete
> (and yet I'm not sure if SPARC really needs all that)...
I just wanted to make sure both setup functions has the same prototype.
I think sparc doesn't need fixing in there.
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: linux-fbdev-devel@lists.sourceforge.net, linuxppc-dev@ozlabs.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, adaplas@gmail.com
Subject: Re: [PATCH 3/3] atyfb: Fix 64 bits resources on 32 bits archs
Date: Wed, 23 Apr 2008 08:20:06 +1000 [thread overview]
Message-ID: <1208902806.9640.136.camel@pasglop> (raw)
In-Reply-To: <480E07BC.3050107@ru.mvista.com>
On Tue, 2008-04-22 at 19:43 +0400, Sergei Shtylyov wrote:
> Not sure what that change gives us -- this function mostly treats 'addr'
> as unsigned long (casting it to char/void *), ot compares it to 'unsigned
> long' 'base' variable -- which should be made 'resource_size_t' in its turn
> being assigned resource's start value. So, this part of patch looks incomplete
> (and yet I'm not sure if SPARC really needs all that)...
I just wanted to make sure both setup functions has the same prototype.
I think sparc doesn't need fixing in there.
Ben.
next prev parent reply other threads:[~2008-04-22 22:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 1:26 [PATCH 3/3] atyfb: Fix 64 bits resources on 32 bits archs Benjamin Herrenschmidt
2008-04-22 1:26 ` Benjamin Herrenschmidt
2008-04-22 1:26 ` Benjamin Herrenschmidt
2008-04-22 15:43 ` Sergei Shtylyov
2008-04-22 15:43 ` Sergei Shtylyov
2008-04-22 22:20 ` Benjamin Herrenschmidt [this message]
2008-04-22 22:20 ` Benjamin Herrenschmidt
2008-04-22 22:20 ` Benjamin Herrenschmidt
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=1208902806.9640.136.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=adaplas@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=sshtylyov@ru.mvista.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.