All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave <dave.jiang@gmail.com>
To: Andrew Morton <akpm@osdl.org>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org,
	smaurer@teja.com, linux@arm.linux.org.uk, dsaxena@plexity.net,
	drew.moseley@intel.com, mporter@kernel.crashing.org
Subject: Re: [PATCH 1/5] Convert resource to u64 from unsigned long
Date: Thu, 13 Jan 2005 17:28:56 -0700	[thread overview]
Message-ID: <8746466a0501131628368e11e1@mail.gmail.com> (raw)
In-Reply-To: <20050113162309.2a125eb1.akpm@osdl.org>

On Thu, 13 Jan 2005 16:23:09 -0800, Andrew Morton <akpm@osdl.org> wrote:
> Dave <dave.jiang@gmail.com> wrote:
> >
> > ere's my first attempt of trying to convert the struct resource
> > start/end to u64 per blessed by Linus =) This is to support >32bit
> > physical address on 32bit archs such as some of the newer ARMv6 and
> > XSC3 based platforms and perhaps IA32 PAE.  I left the PCI stuff alone
> > functionally. Supporting 64bit PCI BAR on 32bit archs is for another
> > day. I fixed most of the core stuff I can think of, fixed ARM and i386
> > hopefully and a few of the device drivers as examples. I have tested
> > on an IQ31244 XScale IOP (ARM) platform and a dual-xeon platform for
> > i386. Matt Porter has graciously sent me PPC fixes that he tested on.
> 
> OK, well Greg KH will be the main target of this work..
> 
> Can you do something a bit more friendly than application/octet-stream
> encoding, btw?
> 
> +#if BITS_PER_LONG == 64
> +#define U64FMT "016lx"
> +#else
> +#define U64FMT "016Lx"
> +#endif
> 
> We've avoided doing this.  We prefer to do
> 
>         printk("%llx", (unsigned long long)foo);
> 
> which is tidier, although a little more runtime-costly.
> 
> Your approach assumes that all 64-bit architectures implement u64 as
> unsigned long (as opposed to unsigned long long, which I guess is legal?) I
> don't know if that's a problem or not.
> 
> Also, the patches introduce tons of ifdefs such as:
> 
> +#if BITS_PER_LONG == 64
>         return (void __iomem *)pci_resource_start(pdev, PCI_ROM_RESOURCE);
> +#else
> +       return (void __iomem *)(u32)pci_resource_start(pdev, PCI_ROM_RESOURCE);
> +#endif
> 
> We really should find a way of avoiding this.  Even if it is
> 
> #if BITS_PER_LONG == 64
> #define resource_to_ptr(r) ((void *)(r))
> #else
> #define resource_to_ptr(r) ((void *)((u32)r))
> #endif
> 
> in a header file somewhere.  Open-coding the decision all over the place is
> unsightly.
> 
 
Ok, I shall rework the patches w/ ull. I wasn't sure that ull would
cause problems on 64bit archs or not for u64....thus the ugly
workarounds....

BTW, anyone know how to inline patches via gmail? 

-- 
-= Dave =-

Software Engineer - Advanced Development Engineering Team 
Storage Component Division - Intel Corp. 
mailto://dave.jiang @ intel
http://sourceforge.net/projects/xscaleiop/
----
The views expressed in this email are
mine alone and do not necessarily 
reflect the views of my employer
(Intel Corp.).

  reply	other threads:[~2005-01-14  0:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-13 23:26 [PATCH 1/5] Convert resource to u64 from unsigned long Dave
2005-01-14  0:23 ` Andrew Morton
2005-01-14  0:28   ` Dave [this message]
2005-01-14  0:43   ` Linus Torvalds
2005-01-14  0:48     ` Dave
2005-01-14  0:52   ` Al Viro
2005-01-14  0:52   ` Russell King
2005-01-14  1:35   ` Jesse Barnes
2005-01-14  3:49     ` Dave
2005-01-14  0:52 ` Greg KH

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=8746466a0501131628368e11e1@mail.gmail.com \
    --to=dave.jiang@gmail.com \
    --cc=akpm@osdl.org \
    --cc=drew.moseley@intel.com \
    --cc=dsaxena@plexity.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mporter@kernel.crashing.org \
    --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.