Re: [PATCH] sparc64: use unsigned long long for u64

[Sam Ravnborg]

On Tue, Dec 23, 2008 at 09:05:44AM -0800, Ken Chen wrote:
> On Tue, Dec 23, 2008 at 5:17 AM, Sam Ravnborg <sam@xxxxxxxxxxxx> wrote:
> > Andrew Morton wrote:
> >
> >    People keep on doing
> >
> >            printk("%llu", some_u64);
> >
> >    testing it only on x86_64 and this generates a warning storm on
> >    powerpc, sparc64, etc.  Because they use `long', not `long long'.
> >
> >    Quite a few 64-bit architectures are using `long' for their
> >    s64/u64 types.  We should convert them all to `long long'.
> >
> > Update types.h so we use unsigned long long for u64 and
> > fix all warnings in sparc64 code.
> > Tested with an allnoconfig, defconfig and allmodconfig builds.
> >
> > This patch introduces additional warnings in several drivers.
> > These will be dealt with in separate patches.
> >
> > Signed-off-by: Sam Ravnborg <sam@xxxxxxxxxxxx>
> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> > ---
> >
> > It may take a few days before the drivers gets fixed.
> > Christmas is approaching fast by now.
> >
> >        Sam
> >
> > diff --git a/arch/sparc/include/asm/timer_64.h b/arch/sparc/include/asm/timer_64.h
> > index 5b779fd..ef3c368 100644
> > --- a/arch/sparc/include/asm/timer_64.h
> > +++ b/arch/sparc/include/asm/timer_64.h
> > @@ -10,7 +10,7 @@
> >  #include <linux/init.h>
> >
> >  struct sparc64_tick_ops {
> > -       unsigned long (*get_tick)(void);
> > +       unsigned long long (*get_tick)(void);
> 
> wait, why does this need to be changed?

We have:
        clocksource_tick.read = tick_ops->get_tick;

And clocksource_tick is of type clocksource:

struct clocksource {
	...
        cycle_t (*read)(void);

And cycle_t is:
/* clocksource cycle base type */
typedef u64 cycle_t;

And u64 is now:
unsigned long long - thus we need to fix prototype
of get_tick to fix the warnings.

A cast could do it - but fixing the real problem
is better here.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/