Re: Assorted warnings while building 2.5.73

Re: Assorted warnings while building 2.5.73

[Petr Vandrovec]

On 25 Jun 03 at 16:25, J.C. Wren wrote:
> drivers/video/matrox/matroxfb_g450.c: In function `g450_compute_bwlevel':
> drivers/video/matrox/matroxfb_g450.c:129: warning: duplicate `const'
> drivers/video/matrox/matroxfb_g450.c:130: warning: duplicate `const'

Fix min/max macros and/or learn gcc that "const typeof(x)" where x
is already const type is OK. Or I can code it with simple if(), but
why we have min/max macros then?

Is there some __attribute__((-Wno-duplicate-const)) ?
                                         Petr Vandrovec
                                         vandrove@vc.cvut.cz
                                         

Re: Assorted warnings while building 2.5.73

[Bob Miller]

On Wed, Jun 25, 2003 at 11:25:35PM +0200, Petr Vandrovec wrote:
> On 25 Jun 03 at 16:25, J.C. Wren wrote:
> > drivers/video/matrox/matroxfb_g450.c: In function `g450_compute_bwlevel':
> > drivers/video/matrox/matroxfb_g450.c:129: warning: duplicate `const'
> > drivers/video/matrox/matroxfb_g450.c:130: warning: duplicate `const'
> 
> Fix min/max macros and/or learn gcc that "const typeof(x)" where x
> is already const type is OK. Or I can code it with simple if(), but
> why we have min/max macros then?
> 
> Is there some __attribute__((-Wno-duplicate-const)) ?
>                                          Petr Vandrovec
>                                          vandrove@vc.cvut.cz
>                                          
> 
Or use a newer compiler that has this fixed, or use min_t()/max_t()
instead.

-- 
Bob Miller					Email: rem@osdl.org
Open Source Development Lab			Phone: 503.626.2455 Ext. 17

Re: [patch] input: Fix CLOCK_TICK_RATE usage ... [8/13]

[Vojtech Pavlik]

On Tue, Jun 17, 2003 at 04:24:04PM -0700, David Mosberger wrote:
> >>>>> On Wed, 18 Jun 2003 01:14:11 +0200, Vojtech Pavlik <vojtech@suse.cz> said:
> 
>   >>  Sounds much better to me.  Wouldn't something along the lines of
>   >> this make the most sense:
> 
>   >> #ifdef __ARCH_PIT_FREQ # define PIT_FREQ __ARCH_PIT_FREQ #else #
>   >> define PIT_FREQ 1193182 #endif
> 
>   >> After all, it seems like the vast majority of legacy-compatible
>   >> hardware _do_ use the standard frequency.
> 
>   Vojtech> Now, if this was in some nice include file, along with the
>   Vojtech> definition of the i8253 PIT spinlock, that'd be
>   Vojtech> great. Because not just the beeper driver uses the PIT,
>   Vojtech> also some joystick code uses it if it is available.
> 
> ftape, too.  The LATCH() macro should also be moved to such a header
> file, I think.  How about just creating asm/pit.h?  Only platforms
> that need to (potentially) support legacy hardware would need to
> define it.  E.g., on ia64, we could do:
> 
>  #ifndef _ASM_IA64_PIT_H
>  #define _ASM_IA64_PIT_H
> 
>  #include <linux/config.h>
> 
>  #ifdef CONFIG_LEGACY_HW
>  # define PIT_FREQ	1193182
>  # define LATCH		((CLOCK_TICK_RATE + HZ/2) / HZ)
>  #endif
> 
>  #endif /* _ASM_IA64_PIT_H */
> 
> This way, machines that support legacy hardware can define
> CONFIG_LEGACY_HW and on others, the macro can be left undefined, so
> that any attempt to compile drivers requiring legacy hw would fail to
> compile upfront (much better than accessing random ports!).

Yes, that looks very good indeed. Riley?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

RE: [patch] input: Fix CLOCK_TICK_RATE usage ... [8/13]

[David Mosberger]

>>>>> On Wed, 25 Jun 2003 09:03:34 +0100, "Riley Williams" <Riley@Williams.Name> said:

  Riley> Hi all.
  Riley> I have no objection to anything along these lines. The basic scenario
  Riley> is simply this:

  Riley> 1. On ALL architectures except for IA64 and ARM there is a SINGLE
  Riley> value for CLOCK_TICK_RATE that is used by several GENERIC drivers.
  Riley> Currently, that value is used as a MAGIC NUMBER that corresponds
  Riley> to the value in the Ix86 case, which is clearly wrong.

What do you mean be "generic"?  AFAIK, the drivers you're talking
about all depend on there being an 8259-style PIT.  As such, they
depend on the 8259 and are not generic.  This dependency should be
made explicit.

BTW: I didn't think Alpha derived its clock-tick from the PIT either,
but I could be misremembering.  Could someone more familiar with Alpha
confirm or deny?

  Riley> 2. According to the IA64 people, those GENERIC drivers are apparently
  Riley> irrelevant for that architecture, so making the CORRECT change of
  Riley> replacing those magic numbers in the GENERIC drivers with the
  Riley> CLOCK_TICK_RATE value will make no difference to IA64.

That's not precise: _some_ ia64 machies do have legacy hardware and
those should be able to use 8259-dependent drivers if they choose to
do so.

Moreover, the current drivers would compile just fine on ia64, even
though they could not possibly work correctly with the current use of
CLOCK_TICK_RATE.  With a separate header file (and a config option),
these dependencies would be made explicit and that would improve
overall cleanliness.

In other words, I still think the right way to go about this is to
have <asm/pit.h>.  On x86, this could be:

--
#include <asm/timex.h>

#define PIT_FREQ	CLOCK_TICK_RATE
#define PIT_LATCH	((PIT_FREQ + HZ/2) / HZ)
--

If you insist, you could even put this in asm-generic, though
personally I don't think that's terribly elegant.

On ia64, <asm/pit.h> could be:

#ifdef CONFIG_PIT
# define PIT_FREQ	1193182
# define PIT_LATCH	((PIT_FREQ + HZ/2) / HZ)
#endif

	--david

Re: [patch] input: Fix CLOCK_TICK_RATE usage ... [8/13]

[Vojtech Pavlik]

On Wed, Jun 25, 2003 at 10:20:59AM -0700, David Mosberger wrote:

> Moreover, the current drivers would compile just fine on ia64, even
> though they could not possibly work correctly with the current use of
> CLOCK_TICK_RATE.  With a separate header file (and a config option),
> these dependencies would be made explicit and that would improve
> overall cleanliness.
> 
> In other words, I still think the right way to go about this is to
> have <asm/pit.h>.  On x86, this could be:
> 
> --
> #include <asm/timex.h>
> 
> #define PIT_FREQ	CLOCK_TICK_RATE
> #define PIT_LATCH	((PIT_FREQ + HZ/2) / HZ)
> --

Actually, I think it should be the other way around:

asm-i386/pit.h:

#define PIT_FREQ	1193182
#define PIT_LATCH	((PIT_FREQ + HZ/2) / HZ)

asm-i386/timex.h:

#include <asm/pit.h>
#define CLOCK_TICK_RATE	PIT_FREQ

> If you insist, you could even put this in asm-generic, though
> personally I don't think that's terribly elegant.
> 
> On ia64, <asm/pit.h> could be:
> 
> #ifdef CONFIG_PIT
> # define PIT_FREQ	1193182
> # define PIT_LATCH	((PIT_FREQ + HZ/2) / HZ)
> #endif
> 
> 	--david

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Assorted warnings while building 2.5.73

[J.C. Wren]

Perhaps I over estimate, but some of these seem of mild concern, primarily the forced conditions.
Does the LKML want to see these, or should I report them via some other mechanism?

fs/fat/inode.c: In function `fat_fill_super':
fs/fat/inode.c:806: warning: comparison is always true due to limited range of data type
fs/ntfs/super.c: In function `is_boot_sector_ntfs':
fs/ntfs/super.c:375: warning: integer constant is too large for "long" type
fs/smbfs/ioctl.c: In function `smb_ioctl':
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
drivers/char/vt_ioctl.c: In function `do_kdsk_ioctl':
drivers/char/vt_ioctl.c:85: warning: comparison is always false due to limited range of data type
drivers/char/vt_ioctl.c:85: warning: comparison is always false due to limited range of data type
drivers/char/vt_ioctl.c: In function `do_kdgkb_ioctl':
drivers/char/vt_ioctl.c:211: warning: comparison is always false due to limited range of data type
drivers/char/keyboard.c: In function `k_fn':
drivers/char/keyboard.c:665: warning: comparison is always true due to limited range of data type
drivers/ide/ide-probe.c: In function `hwif_check_region':
drivers/ide/ide-probe.c:644: warning: `check_region' is deprecated (declared at include/linux/ioport.h:116)
drivers/serial/8250.c: In function `serial8250_set_termios':
drivers/serial/8250.c:1428: warning: comparison is always false due to limited range of data type
drivers/video/matrox/matroxfb_g450.c: In function `g450_compute_bwlevel':
drivers/video/matrox/matroxfb_g450.c:129: warning: duplicate `const'
drivers/video/matrox/matroxfb_g450.c:130: warning: duplicate `const'
net/ipv4/igmp.c: In function `igmp_rcv':
net/ipv4/igmp.c:851: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1129)
arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff
drivers/i2c/i2c-sensor.c: In function `i2c_detect':
drivers/i2c/i2c-sensor.c:54: warning: `check_region' is deprecated (declared at include/linux/ioport.h:116)
drivers/ieee1394/raw1394.c: In function `arm_register':
drivers/ieee1394/raw1394.c:1569: warning: integer constant is too large for "long" type
drivers/ieee1394/raw1394.c:1570: warning: integer constant is too large for "long" type
	
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs
Configured with: /var/tmp/portage/gcc-3.3/work/gcc-3.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,ada,f77,objc,java --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-interpreter --enable-java-awt=xlib --with-x
Thread model: posix
gcc version 3.3 (Gentoo Linux 1.4, PVR 3.3)