From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758180AbYIDUkW (ORCPT ); Thu, 4 Sep 2008 16:40:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754106AbYIDUkF (ORCPT ); Thu, 4 Sep 2008 16:40:05 -0400 Received: from nelson.telenet-ops.be ([195.130.133.66]:34464 "EHLO nelson.telenet-ops.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753397AbYIDUkD (ORCPT ); Thu, 4 Sep 2008 16:40:03 -0400 Date: Thu, 4 Sep 2008 22:40:00 +0200 (CEST) From: Geert Uytterhoeven To: Helge Deller cc: linux-parisc@vger.kernel.org, Linux/m68k , Linux Kernel Development Subject: Re: __kernel_suseconds_t is int on PA-RISC (and SPARC64)? In-Reply-To: <48B46672.1000902@gmx.de> Message-ID: References: <48B46672.1000902@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 26 Aug 2008, Helge Deller wrote: > Geert Uytterhoeven wrote: > > Apparently __kernel_suseconds_t is `int' on PA-RISC (and on SPARC64), > > while it's `long' on all other platforms. > > > > Is there a specific reason for that? > > I don't know for sure, but arch/parisc/kernel/syscall_table.S states: > /* even though manpage says struct timeval contains longs, ours has > * time_t and suseconds_t -- both of which are safe wide/narrow */ > ENTRY_COMP(setitimer) > > So it was probably chosen to be int so that it can be easily used in 32- and > 64bit kernels (or compat code). > > > This causes compiler warnings in the HP SDC Real Time Clock driver, > > which is shared between PA-RISC and m68k: Here's a patch to fix the compiler warnings. Is this OK for PA-RISC? SUbject: [PATCH] HP input: kill warnings due to suseconds_t differences Kill compiler warnings related to printf() formats in the input drivers for various HP9000 machines, which are shared between PA-RISC (suseconds_t is int) and m68k (suseconds_t is long). As both are 32-bit, it's safe to cast to int. Signed-off-by: Geert Uytterhoeven --- drivers/input/misc/hp_sdc_rtc.c | 10 +++++----- drivers/input/serio/hp_sdc.c | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) --- a/drivers/input/misc/hp_sdc_rtc.c +++ b/drivers/input/misc/hp_sdc_rtc.c @@ -458,35 +458,35 @@ static int hp_sdc_rtc_proc_output (char p += sprintf(p, "i8042 rtc\t: READ FAILED!\n"); } else { p += sprintf(p, "i8042 rtc\t: %ld.%02d seconds\n", - tv.tv_sec, tv.tv_usec/1000); + tv.tv_sec, (int)tv.tv_usec/1000); } if (hp_sdc_rtc_read_fhs(&tv)) { p += sprintf(p, "handshake\t: READ FAILED!\n"); } else { p += sprintf(p, "handshake\t: %ld.%02d seconds\n", - tv.tv_sec, tv.tv_usec/1000); + tv.tv_sec, (int)tv.tv_usec/1000); } if (hp_sdc_rtc_read_mt(&tv)) { p += sprintf(p, "alarm\t\t: READ FAILED!\n"); } else { p += sprintf(p, "alarm\t\t: %ld.%02d seconds\n", - tv.tv_sec, tv.tv_usec/1000); + tv.tv_sec, (int)tv.tv_usec/1000); } if (hp_sdc_rtc_read_dt(&tv)) { p += sprintf(p, "delay\t\t: READ FAILED!\n"); } else { p += sprintf(p, "delay\t\t: %ld.%02d seconds\n", - tv.tv_sec, tv.tv_usec/1000); + tv.tv_sec, (int)tv.tv_usec/1000); } if (hp_sdc_rtc_read_ct(&tv)) { p += sprintf(p, "periodic\t: READ FAILED!\n"); } else { p += sprintf(p, "periodic\t: %ld.%02d seconds\n", - tv.tv_sec, tv.tv_usec/1000); + tv.tv_sec, (int)tv.tv_usec/1000); } p += sprintf(p, --- a/drivers/input/serio/hp_sdc.c +++ b/drivers/input/serio/hp_sdc.c @@ -323,7 +323,7 @@ static void hp_sdc_tasklet(unsigned long * it back to the application. and be less verbose. */ printk(KERN_WARNING PREFIX "read timeout (%ius)!\n", - tv.tv_usec - hp_sdc.rtv.tv_usec); + (int)(tv.tv_usec - hp_sdc.rtv.tv_usec)); curr->idx += hp_sdc.rqty; hp_sdc.rqty = 0; tmp = curr->seq[curr->actidx]; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds