From: "Randy.Dunlap" <rddunlap@osdl.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Dave <dave.jiang@gmail.com>,
linux-kernel@vger.kernel.org, smaurer@teja.com,
linux@arm.linux.org.uk, dsaxena@plexity.net,
drew.moseley@intel.com
Subject: Re: clean way to support >32bit addr on 32bit CPU
Date: Mon, 10 Jan 2005 16:28:05 -0800 [thread overview]
Message-ID: <41E31D95.50205@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0501101607240.2373@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 10 Jan 2005, Dave wrote:
>
>>After all said and done, the struct resource members start and end
>>must support 64bit integer values in order to work. On a 64bit arch
>>that would be fine since unsigned long is 64bit. However on a 32bit
>>arch one must use unsigned long long to get 64bit.
>
>
> We really should make "struct resource" use u64's. It's wrong even on x86,
> but we've never seen any real problems in practice, so we've had little
> reason to bother.
>
> This has definitely come up before, maybe there's even some old patch
> floating around. It should be as easy as just fixing up "start/end" to be
> "u64" (and perhaps move them to the beginning of the struct to make sure
> packing is ok on all architectures), and fixing any fall-out.
Speaking of fall-out, or more like trickle-down,
I'm almost done with a patch to make PCMCIA resources use
unsigned long instead of u_int or u_short for IO address:
incluce/pcmcia/cs_types.h:
#if defined(__arm__) || defined(__mips__)
typedef u_int ioaddr_t;
#else
typedef u_short ioaddr_t;
#endif
becomes:
typedef unsigned long ioaddr_t;
and then include/pcmcia/cs.c needs some changes in use of
ioaddr_t, along with drivers (printk formats).
Does that sound OK?
I guess that it would become unsigned long long (or u64)
with this proposal?
--
~Randy
next prev parent reply other threads:[~2005-01-11 0:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-10 23:34 clean way to support >32bit addr on 32bit CPU Dave
2005-01-11 0:01 ` Slade Maurer
2005-01-11 0:00 ` Deepak Saxena
2005-01-11 0:35 ` Slade Maurer
2005-01-11 0:04 ` Roland Dreier
2005-01-11 0:09 ` Linus Torvalds
2005-01-11 0:28 ` Randy.Dunlap [this message]
2005-01-11 1:30 ` Linus Torvalds
2005-01-11 2:05 ` William Lee Irwin III
2005-01-11 3:38 ` Randy.Dunlap
2005-01-11 17:39 ` Randy.Dunlap
2005-01-11 18:18 ` Linus Torvalds
2005-01-11 19:40 ` Dave
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=41E31D95.50205@osdl.org \
--to=rddunlap@osdl.org \
--cc=dave.jiang@gmail.com \
--cc=drew.moseley@intel.com \
--cc=dsaxena@plexity.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=smaurer@teja.com \
--cc=torvalds@osdl.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 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.