arch/powerpc/kernel/setup_64.c:447:5: warning: "kernstart_addr" is not defined
arch/powerpc/kernel/setup_64.c:447:5: warning: "kernstart_addr" is not defined
kernel/resource.c: In function '__reserve_region_with_split':
kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t'
sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
lib/debugobjects.c:58: warning: 'obj_states' defined but not used
net/dccp/options.c: In function 'dccp_parse_options':
net/dccp/options.c:67: warning: 'value' may be used uninitialized in this function
sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_write':
sound/soc/codecs/tlv320aic23.c:104: warning: passing argument 2 of 'codec->hw_write' makes pointer from integer without a cast
sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_set_dai_sysclk':
sound/soc/codecs/tlv320aic23.c:424: warning: unused variable 'codec'
drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax'
drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
drivers/dma/ioat_dca.c:91: error: implicit declaration of function 'boot_cpu_has'
drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in this function)
drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only once
drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
drivers/dma/ioat_dca.c:190: error: implicit declaration of function 'cpu_physical_id'
fs/ext4/balloc.c: In function 'ext4_claim_free_blocks':
fs/ext4/balloc.c:607: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64'
fs/ext4/inode.c: In function 'ext4_print_free_blocks':
fs/ext4/inode.c:1822: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64'
fs/ext4/inode.c:1824: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64'
net/sched/sch_generic.c: In function 'dev_watchdog':
net/sched/sch_generic.c:224: warning: unused variable 'drivername'
net/mac80211/rc80211_minstrel_debugfs.c: In function 'minstrel_stats_open':
net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 11 has type 'u64'
net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 12 has type 'u64'
net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 11 has type 'u64'
net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 12 has type 'u64'
net/mac80211/rc80211_minstrel_debugfs.c: At top level:
net/mac80211/rc80211_minstrel_debugfs.c:145: warning: initialization from incompatible pointer type
drivers/ide/pci/scc_pata.c: In function 'init_hwif_scc':
drivers/ide/pci/scc_pata.c:846: warning: unused variable 'ports'
drivers/ide/pci/hpt366.c: In function 'init_hwif_hpt366':
drivers/ide/pci/hpt366.c:1292: warning: unused variable 'dev'
include/linux/ucb1400.h:139: warning: 'ucb1400_adc_read' defined but not used
drivers/mtd/devices/docprobe.c:80:2: warning: #warning Unknown architecture for DiskOnChip. No default probe locations defined
fs/ocfs2/xattr.c: In function 'ocfs2_xattr_index_block_find':
fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_iterate_xattr_buckets':
fs/ocfs2/xattr.c:2424: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:2424: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:2424: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:2443: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:2443: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:2443: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_xattr_create_index_block':
fs/ocfs2/xattr.c:2779: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:2779: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:2779: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_defrag_xattr_bucket':
fs/ocfs2/xattr.c:2942: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:2942: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:2942: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_mv_xattr_bucket_cross_cluster':
fs/ocfs2/xattr.c:3060: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3060: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:3060: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3060: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:3060: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3060: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_half_xattr_bucket':
fs/ocfs2/xattr.c:3189: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3189: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:3189: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3189: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:3189: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3189: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_cp_xattr_bucket':
fs/ocfs2/xattr.c:3360: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3360: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:3360: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3360: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:3360: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3360: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_cp_xattr_cluster':
fs/ocfs2/xattr.c:3431: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3431: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:3431: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3431: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:3431: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3431: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_adjust_xattr_cross_cluster':
fs/ocfs2/xattr.c:3561: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3561: warning: format '%llu' expects type 'long long unsigned int', but argument 8 has type 'u64'
fs/ocfs2/xattr.c:3561: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3561: warning: format '%llu' expects type 'long long unsigned int', but argument 8 has type 'u64'
fs/ocfs2/xattr.c:3561: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3561: warning: format '%llu' expects type 'long long unsigned int', but argument 8 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_add_new_xattr_cluster':
fs/ocfs2/xattr.c:3629: warning: format '%llu' expects type 'long long unsigned int', but argument 8 has type 'u64'
fs/ocfs2/xattr.c:3629: warning: format '%llu' expects type 'long long unsigned int', but argument 8 has type 'u64'
fs/ocfs2/xattr.c:3629: warning: format '%llu' expects type 'long long unsigned int', but argument 8 has type 'u64'
fs/ocfs2/xattr.c:3718: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:3718: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:3718: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_extend_xattr_bucket':
fs/ocfs2/xattr.c:3763: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3763: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:3763: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
sound/pci/hda/patch_sigmatel.c: In function 'stac92xx_parse_auto_config':
sound/pci/hda/patch_sigmatel.c:2819: warning: 'nid' may be used uninitialized in this function
drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read':
drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function '__raw_readl'
drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write':
drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function '__raw_writel'
drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe':
drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 'ioremap'
drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from integer without a cast
drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 'iounmap'
make[2]: [drivers/rtc/rtc-ds1286.o] Error 1 (ignored)
drivers/serial/serial_txx9.c: In function 'serial_txx9_probe':
drivers/serial/serial_txx9.c:1041: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long unsigned int'
drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time':
drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb'
drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 'writeb'
drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe':
drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 'ioremap'
drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from integer without a cast
drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 'iounmap'
drivers/net/ibm_newemac/mal.c: In function 'mal_txeob':
drivers/net/ibm_newemac/mal.c:284: error: implicit declaration of function 'mtdcri'
drivers/net/ibm_newemac/mal.c:284: error: 'SDR0' undeclared (first use in this function)
drivers/net/ibm_newemac/mal.c:284: error: (Each undeclared identifier is reported only once
drivers/net/ibm_newemac/mal.c:284: error: for each function it appears in.)
drivers/net/ibm_newemac/mal.c:285: error: implicit declaration of function 'mfdcri'
drivers/net/ibm_newemac/mal.c: In function 'mal_rxeob':
drivers/net/ibm_newemac/mal.c:302: error: 'SDR0' undeclared (first use in this function)
drivers/media/dvb/frontends/cx24116.c: In function 'cx24116_load_firmware':
drivers/media/dvb/frontends/cx24116.c:573: warning: passing argument 3 of 'cx24116_writeregN' discards qualifiers from pointer target type
drivers/video/aty/aty128fb.c: In function 'aty128_decode_var':
drivers/video/aty/aty128fb.c:1520: warning: 'pll.post_divider' may be used uninitialized in this function
drivers/net/wireless/libertas_tf/if_usb.c: In function '__if_usb_submit_rx_urb':
drivers/net/wireless/libertas_tf/if_usb.c:334: warning: cast to pointer from integer of different size
drivers/media/dvb/frontends/z0194a.h:85: warning: 'sharp_z0194a_config' defined but not used
drivers/media/video/gspca/ov519.c: In function 'mode_init_ov_sensor_regs':
drivers/media/video/gspca/ov519.c:1670: warning: comparison is always true due to limited range of data type
Documentation/video4linux/v4lgrab.c: In function 'main':
Documentation/video4linux/v4lgrab.c:184: warning: 'src_depth' is used uninitialized in this function
Documentation/video4linux/v4lgrab.c:99: warning: 'b' may be used uninitialized in this function
Documentation/video4linux/v4lgrab.c:99: warning: 'g' may be used uninitialized in this function
Documentation/video4linux/v4lgrab.c:99: warning: 'r' may be used uninitialized in this function
Documentation/accounting/getdelays.c: In function 'main':
Documentation/accounting/getdelays.c:249: warning: 'cmd_type' may be used uninitialized in this function
Documentation/connector/cn_test.c:45: warning: 'cn_test_want_notify' defined but not used
Some comments for some of these...
On Wed, 2008-10-15 at 21:33 -0700, Andrew Morton wrote:
> kernel/resource.c: In function '__reserve_region_with_split':
> kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
> kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
> kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t'
> kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t'
This is a generic code bug, I sent a patch for it a day or two ago. (ie
those are real bugs on 32-bit resource_size_t)
> drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
> drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax'
> drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
> drivers/dma/ioat_dca.c:91: error: implicit declaration of function 'boot_cpu_has'
> drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in this function)
> drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only once
> drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
> drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
> drivers/dma/ioat_dca.c:190: error: implicit declaration of function 'cpu_physical_id'
Looks like this driver should depend on X86 :-)
> fs/ext4/balloc.c: In function 'ext4_claim_free_blocks':
> fs/ext4/balloc.c:607: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64'
> fs/ext4/inode.c: In function 'ext4_print_free_blocks':
> fs/ext4/inode.c:1822: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64'
> fs/ext4/inode.c:1824: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64'
The above are unfortunate but at least aren't bugs per-se, just
annoying. Should be fixable with casts. Ted ?
> net/mac80211/rc80211_minstrel_debugfs.c: In function 'minstrel_stats_open':
> net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 11 has type 'u64'
> net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 12 has type 'u64'
> net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 11 has type 'u64'
> net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 12 has type 'u64'
> net/mac80211/rc80211_minstrel_debugfs.c: At top level:
> net/mac80211/rc80211_minstrel_debugfs.c:145: warning: initialization from incompatible pointer type
Same.
> fs/ocfs2/xattr.c: In function 'ocfs2_xattr_index_block_find':
> fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
> fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
.../...
same
>
> sound/pci/hda/patch_sigmatel.c: In function 'stac92xx_parse_auto_config':
> sound/pci/hda/patch_sigmatel.c:2819: warning: 'nid' may be used uninitialized in this function
>
> drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read':
> drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function '__raw_readl'
> drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write':
> drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function '__raw_writel'
> drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe':
> drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 'ioremap'
> drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from integer without a cast
> drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 'iounmap'
> make[2]: [drivers/rtc/rtc-ds1286.o] Error 1 (ignored)
Missing #include <asm/io.h> ?
> drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time':
> drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb'
> drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 'writeb'
> drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe':
> drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 'ioremap'
> drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from integer without a cast
> drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 'iounmap'
Same ?
> drivers/net/ibm_newemac/mal.c: In function 'mal_txeob':
> drivers/net/ibm_newemac/mal.c:284: error: implicit declaration of function 'mtdcri'
> drivers/net/ibm_newemac/mal.c:284: error: 'SDR0' undeclared (first use in this function)
> drivers/net/ibm_newemac/mal.c:284: error: (Each undeclared identifier is reported only once
> drivers/net/ibm_newemac/mal.c:284: error: for each function it appears in.)
> drivers/net/ibm_newemac/mal.c:285: error: implicit declaration of function 'mfdcri'
> drivers/net/ibm_newemac/mal.c: In function 'mal_rxeob':
> drivers/net/ibm_newemac/mal.c:302: error: 'SDR0' undeclared (first use in this function)
That's annoying, I'll have a look.
> drivers/net/wireless/libertas_tf/if_usb.c: In function '__if_usb_submit_rx_urb':
> drivers/net/wireless/libertas_tf/if_usb.c:334: warning: cast to pointer from integer of different size
Yuck !
I'll look at the EMAC one and maybe some more tomorrow if nobody beats
me to it.
Cheers,
Ben.
From: Andrew Morton <[email protected]>
Date: Wed, 15 Oct 2008 21:33:37 -0700
> kernel/resource.c: In function '__reserve_region_with_split':
> kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
> kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
> kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t'
> kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t'
Known issue, Ben wants to add a new variant of %pX in order to print resources so that
resource_size_t vs. unsigned long stuff doesn't matter like this any more.
> net/dccp/options.c: In function 'dccp_parse_options':
> net/dccp/options.c:67: warning: 'value' may be used uninitialized in this function
Known issue, not trivial to fix, gcc is just being incredibly silly here as it
can't see all of the control flow.
> drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
> drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax'
> drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
> drivers/dma/ioat_dca.c:91: error: implicit declaration of function 'boot_cpu_has'
> drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in this function)
> drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only once
> drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
> drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
> drivers/dma/ioat_dca.c:190: error: implicit declaration of function 'cpu_physical_id'
Known issue. I tried to ping Jeff Garzik about doing a driver bug fix run in
order to fix this, but he hasn't shown any signs of life.
So I'll do it myself later tonight. :-/
> net/sched/sch_generic.c: In function 'dev_watchdog':
> net/sched/sch_generic.c:224: warning: unused variable 'drivername'
Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer
on the stack looks unused.
> drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read':
> drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function '__raw_readl'
> drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write':
> drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function '__raw_writel'
> drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe':
> drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 'ioremap'
> drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from integer without a cast
> drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 'iounmap'
Missing asm/io.h include.
> drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time':
> drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb'
> drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 'writeb'
> drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe':
> drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 'ioremap'
> drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from integer without a cast
> drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 'iounmap'
Likewise.
> drivers/net/wireless/libertas_tf/if_usb.c: In function '__if_usb_submit_rx_urb':
> drivers/net/wireless/libertas_tf/if_usb.c:334: warning: cast to pointer from integer of different size
I've seen this one on sparc64 too, I think the arg is totally unused in the end
for this callback control flow and we can just use NULL or zero instead.
On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
> From: Andrew Morton <akpm-de/[email protected]>
> Date: Wed, 15 Oct 2008 21:33:37 -0700
>
> > kernel/resource.c: In function '__reserve_region_with_split':
> > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
> > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
> > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t'
> > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t'
>
> Known issue, Ben wants to add a new variant of %pX in order to print resources so that
> resource_size_t vs. unsigned long stuff doesn't matter like this any more.
Actually, I was told Linus had one and I've been trying to dig it out...
Oh well, I may as well dig my own old one.
Cheers,
Ben.
At Wed, 15 Oct 2008 21:33:37 -0700,
Andrew Morton wrote:
>
> sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
These are definitions of deprecated interfaces.
We can remove it in 2.6.29. If we don't want to be conservative, it
can be removed in 2.6.28, too.
> sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_write':
> sound/soc/codecs/tlv320aic23.c:104: warning: passing argument 2 of 'codec->hw_write' makes pointer from integer without a cast
> sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_set_dai_sysclk':
> sound/soc/codecs/tlv320aic23.c:424: warning: unused variable 'codec'
The fix was in the pending pull request.
> sound/pci/hda/patch_sigmatel.c: In function 'stac92xx_parse_auto_config':
> sound/pci/hda/patch_sigmatel.c:2819: warning: 'nid' may be used uninitialized in this function
Ditto.
thanks,
Takashi
On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
> > drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
> > drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax'
> > drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
> > drivers/dma/ioat_dca.c:91: error: implicit declaration of function 'boot_cpu_has'
> > drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in this function)
> > drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only once
> > drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
> > drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
> > drivers/dma/ioat_dca.c:190: error: implicit declaration of function 'cpu_physical_id'
>
> Known issue. I tried to ping Jeff Garzik about doing a driver bug fix run in
> order to fix this, but he hasn't shown any signs of life.
>
> So I'll do it myself later tonight. :-/
>
The following seems to fix this up...
---snip--->
ixgbe, myri10ge: INTEL_IOATDMA can only be selected when X86=y
From: Dan Williams <[email protected]>
The INTEL_IOATDMA symbol depends on x86. 'select' ignores this
dependency.
Cc: Brice Goglin <[email protected]>
Cc: Jesse Brandeburg <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
---
drivers/net/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 1d8af33..84983f8 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2410,7 +2410,7 @@ config IXGBE
tristate "Intel(R) 10GbE PCI Express adapters support"
depends on PCI && INET
select INET_LRO
- select INTEL_IOATDMA
+ select INTEL_IOATDMA if X86
---help---
This driver supports Intel(R) 10GbE PCI Express family of
adapters. For more information on how to identify your adapter, go
@@ -2462,7 +2462,7 @@ config MYRI10GE
select FW_LOADER
select CRC32
select INET_LRO
- select INTEL_IOATDMA
+ select INTEL_IOATDMA if X86
---help---
This driver supports Myricom Myri-10G Dual Protocol interface in
Ethernet mode. If the eeprom on your board is not recent enough,
Dan Williams wrote:
> On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
>
>>> drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
>>> drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax'
>>> drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
>>> drivers/dma/ioat_dca.c:91: error: implicit declaration of function 'boot_cpu_has'
>>> drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in this function)
>>> drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only once
>>> drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
>>> drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
>>> drivers/dma/ioat_dca.c:190: error: implicit declaration of function 'cpu_physical_id'
>>>
>> Known issue. I tried to ping Jeff Garzik about doing a driver bug fix run in
>> order to fix this, but he hasn't shown any signs of life.
>>
>> So I'll do it myself later tonight. :-/
>>
>>
> The following seems to fix this up...
>
> ---snip--->
> ixgbe, myri10ge: INTEL_IOATDMA can only be selected when X86=y
>
There's already a completely different fix queued in netdev patchworks
(for myri10ge only right now, to be duplicated for Intel drivers). The
idea is to stop having almost-unrelated drivers select each other
directly, let people select which drivers they really want, and have
Kconfig handle modules/builtin-stuff correctly. See
http://patchwork.ozlabs.org/patch/4506/
Brice
From: Brice Goglin <[email protected]>
Date: Thu, 16 Oct 2008 08:55:08 +0200
> Dan Williams wrote:
> > On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
> >
> >>> drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
> >>> drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax'
> >>> drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
> >>> drivers/dma/ioat_dca.c:91: error: implicit declaration of function 'boot_cpu_has'
> >>> drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in this function)
> >>> drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only once
> >>> drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
> >>> drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
> >>> drivers/dma/ioat_dca.c:190: error: implicit declaration of function 'cpu_physical_id'
> >>>
> >> Known issue. I tried to ping Jeff Garzik about doing a driver bug fix run in
> >> order to fix this, but he hasn't shown any signs of life.
> >>
> >> So I'll do it myself later tonight. :-/
> >>
> >>
> > The following seems to fix this up...
> >
> > ---snip--->
> > ixgbe, myri10ge: INTEL_IOATDMA can only be selected when X86=y
> >
>
> There's already a completely different fix queued in netdev patchworks
> (for myri10ge only right now, to be duplicated for Intel drivers). The
> idea is to stop having almost-unrelated drivers select each other
> directly, let people select which drivers they really want, and have
> Kconfig handle modules/builtin-stuff correctly. See
> http://patchwork.ozlabs.org/patch/4506/
Right, my plan was to duplicate this for the other drivers.
On Wed, 15 Oct 2008, David Miller wrote:
> > kernel/resource.c: In function '__reserve_region_with_split':
> > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
> > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
> > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t'
> > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t'
>
> Known issue, Ben wants to add a new variant of %pX in order to print resources so that
> resource_size_t vs. unsigned long stuff doesn't matter like this any more.
Will still give a warning, as resource_size_t is not a pointer.
> > drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read':
> > drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function '__raw_readl'
> > drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write':
> > drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function '__raw_writel'
> > drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe':
> > drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 'ioremap'
> > drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from integer without a cast
> > drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 'iounmap'
>
> Missing asm/io.h include.
Nah, <linux/io.h> ;-)
> > drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time':
> > drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb'
> > drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 'writeb'
> > drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe':
> > drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 'ioremap'
> > drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from integer without a cast
> > drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 'iounmap'
>
> Likewise.
Already sent a patch for these two...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
From: Geert Uytterhoeven <[email protected]>
Date: Thu, 16 Oct 2008 09:31:29 +0200 (CEST)
> On Wed, 15 Oct 2008, David Miller wrote:
> > > kernel/resource.c: In function '__reserve_region_with_split':
> > > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
> > > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
> > > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t'
> > > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t'
> >
> > Known issue, Ben wants to add a new variant of %pX in order to print resources so that
> > resource_size_t vs. unsigned long stuff doesn't matter like this any more.
>
> Will still give a warning, as resource_size_t is not a pointer.
The idea is to pass in a pointer to the resource struct,
and the %pX variant specified says what part to print.
On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
> At Wed, 15 Oct 2008 21:33:37 -0700,
> Andrew Morton wrote:
> >
> > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
>
> These are definitions of deprecated interfaces.
> We can remove it in 2.6.29. If we don't want to be conservative, it
> can be removed in 2.6.28, too.
>...
Since it's an in-kernel API there's no reason to keep it once there are
no users left.
But currently sound/soc/at32/playpaq_wm8510.c still seems to use it.
> thanks,
>
> Takashi
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
At Thu, 16 Oct 2008 10:38:36 +0300,
Adrian Bunk wrote:
>
> On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
> > At Wed, 15 Oct 2008 21:33:37 -0700,
> > Andrew Morton wrote:
> > >
> > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> >
> > These are definitions of deprecated interfaces.
> > We can remove it in 2.6.29. If we don't want to be conservative, it
> > can be removed in 2.6.28, too.
> >...
>
> Since it's an in-kernel API there's no reason to keep it once there are
> no users left.
Right. But, IMO, now is no suitable time.
A thing like API removal should have been tested in linux-next, and we
had plenty of time indeed for 2.6.28.
> But currently sound/soc/at32/playpaq_wm8510.c still seems to use it.
Yep, but don't be bothered to try to create a patch for that.
There will be a unification patch for both at32 and at91, so clean-ups
will be applied anyway later.
thanks,
Takashi
On Thu, 16 Oct 2008, David Miller wrote:
> From: Geert Uytterhoeven <[email protected]>
> Date: Thu, 16 Oct 2008 09:31:29 +0200 (CEST)
>
> > On Wed, 15 Oct 2008, David Miller wrote:
> > > > kernel/resource.c: In function '__reserve_region_with_split':
> > > > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
> > > > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
> > > > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t'
> > > > kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t'
> > >
> > > Known issue, Ben wants to add a new variant of %pX in order to print resources so that
> > > resource_size_t vs. unsigned long stuff doesn't matter like this any more.
> >
> > Will still give a warning, as resource_size_t is not a pointer.
>
> The idea is to pass in a pointer to the resource struct,
> and the %pX variant specified says what part to print.
Neat! So we can also have a separate variant to print the resource
range.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
> At Thu, 16 Oct 2008 10:38:36 +0300,
> Adrian Bunk wrote:
> >
> > On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
> > > At Wed, 15 Oct 2008 21:33:37 -0700,
> > > Andrew Morton wrote:
> > > >
> > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> > >
> > > These are definitions of deprecated interfaces.
> > > We can remove it in 2.6.29. If we don't want to be conservative, it
> > > can be removed in 2.6.28, too.
> > >...
> >
> > Since it's an in-kernel API there's no reason to keep it once there are
> > no users left.
>
> Right. But, IMO, now is no suitable time.
> A thing like API removal should have been tested in linux-next, and we
> had plenty of time indeed for 2.6.28.
>...
A grep through the tree and one test compile that covers
sound/soc/soc-dapm.c should be enough testing.
And having it then in -next once should be enough to discover if someone
wrongly added a new user.
I have removed many functions in the kernel, and there isn't much that
can go wrong - even adding a PCI ID to a driver has a bigger risk of
introducing a regression.
> thanks,
>
> Takashi
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
At Thu, 16 Oct 2008 11:21:57 +0300,
Adrian Bunk wrote:
>
> On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
> > At Thu, 16 Oct 2008 10:38:36 +0300,
> > Adrian Bunk wrote:
> > >
> > > On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
> > > > At Wed, 15 Oct 2008 21:33:37 -0700,
> > > > Andrew Morton wrote:
> > > > >
> > > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > >
> > > > These are definitions of deprecated interfaces.
> > > > We can remove it in 2.6.29. If we don't want to be conservative, it
> > > > can be removed in 2.6.28, too.
> > > >...
> > >
> > > Since it's an in-kernel API there's no reason to keep it once there are
> > > no users left.
> >
> > Right. But, IMO, now is no suitable time.
> > A thing like API removal should have been tested in linux-next, and we
> > had plenty of time indeed for 2.6.28.
> >...
>
> A grep through the tree and one test compile that covers
> sound/soc/soc-dapm.c should be enough testing.
>
> And having it then in -next once should be enough to discover if someone
> wrongly added a new user.
My point is the time for removal. The API changes should have been
done in the merge window, and it should have been tested *before* the
merge window.
> I have removed many functions in the kernel, and there isn't much that
> can go wrong - even adding a PCI ID to a driver has a bigger risk of
> introducing a regression.
Yeah, IMHO, adding PCI IDs blindly at the late stage should be
avoided, too, although many people love that.
thanks,
Takashi
On Wed, Oct 15, 2008 at 09:33:37PM -0700, Andrew Morton wrote:
> sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
I should submit the patch to remove this now that 2.6.27 is out - the
warnings are generated by EXPORT_SYMBOL_GPL() - I couldn't see a way to
mark the function as deprecated without removing the export.
> sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_write':
> sound/soc/codecs/tlv320aic23.c:104: warning: passing argument 2 of 'codec->hw_write' makes pointer from integer without a cast
> sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_set_dai_sysclk':
> sound/soc/codecs/tlv320aic23.c:424: warning: unused variable 'codec'
The author already provided a patch to fix these. Takashi has sent a
pull request to Linus including that already, IIRC.
On Thu, Oct 16, 2008 at 10:43:33AM +0200, Takashi Iwai wrote:
> At Thu, 16 Oct 2008 11:21:57 +0300,
> Adrian Bunk wrote:
> >
> > On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
> > > At Thu, 16 Oct 2008 10:38:36 +0300,
> > > Adrian Bunk wrote:
> > > >
> > > > On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
> > > > > At Wed, 15 Oct 2008 21:33:37 -0700,
> > > > > Andrew Morton wrote:
> > > > > >
> > > > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > > >
> > > > > These are definitions of deprecated interfaces.
> > > > > We can remove it in 2.6.29. If we don't want to be conservative, it
> > > > > can be removed in 2.6.28, too.
> > > > >...
> > > >
> > > > Since it's an in-kernel API there's no reason to keep it once there are
> > > > no users left.
> > >
> > > Right. But, IMO, now is no suitable time.
> > > A thing like API removal should have been tested in linux-next, and we
> > > had plenty of time indeed for 2.6.28.
> > >...
> >
> > A grep through the tree and one test compile that covers
> > sound/soc/soc-dapm.c should be enough testing.
> >
> > And having it then in -next once should be enough to discover if someone
> > wrongly added a new user.
>
> My point is the time for removal. The API changes should have been
> done in the merge window, and it should have been tested *before* the
> merge window.
>...
My point is simply that compared to many other patches that weren't
tested before the merge window, and that still get (for various reasons)
into the tree, the removal of unused functions is extremely low-risk
(assuming the patch creator knows what grep is and does a test compile
of the changed code).
> thanks,
>
> Takashi
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
>
>
> > net/sched/sch_generic.c: In function 'dev_watchdog':
> > net/sched/sch_generic.c:224: warning: unused variable 'drivername'
>
> Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer
> on the stack looks unused.
I've complained about this to Arjan before, we actually lose all
messages passed to WARN() or WARN_ONCE() on platforms that use bug traps
for warnings too.
johannes
On Wed, Oct 15, 2008 at 11:58 PM, David Miller <[email protected]> wrote:
>> There's already a completely different fix queued in netdev patchworks
>> (for myri10ge only right now, to be duplicated for Intel drivers). The
>> idea is to stop having almost-unrelated drivers select each other
>> directly, let people select which drivers they really want, and have
>> Kconfig handle modules/builtin-stuff correctly. See
>> http://patchwork.ozlabs.org/patch/4506/
>
> Right, my plan was to duplicate this for the other drivers.
The work is already done for ixgbe and igb, and we have it in testing.
It should be in your inbox today or tomorrow.
From: Johannes Berg <[email protected]>
Date: Thu, 16 Oct 2008 16:57:19 +0200
> On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
> >
> >
> > > net/sched/sch_generic.c: In function 'dev_watchdog':
> > > net/sched/sch_generic.c:224: warning: unused variable 'drivername'
> >
> > Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer
> > on the stack looks unused.
>
> I've complained about this to Arjan before, we actually lose all
> messages passed to WARN() or WARN_ONCE() on platforms that use bug traps
> for warnings too.
Ok I see how that works, yes, it should be fixed.
If the platform defines a __WARN (which powerpc does) the
whole format string and printf args go unevaluated, it's
because of the following sequence in asm-generic/bug.h:
#ifndef __WARN
#ifndef __ASSEMBLY__
extern void warn_on_slowpath(const char *file, const int line);
extern void warn_slowpath(const char *file, const int line,
const char *fmt, ...) __attribute__((format(printf, 3, 4)));
#define WANT_WARN_ON_SLOWPATH
#endif
#define __WARN() warn_on_slowpath(__FILE__, __LINE__)
#define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
#else
#define __WARN_printf(arg...) __WARN()
#endif
On Thu, 16 Oct 2008 12:49:23 -0700 (PDT)
David Miller <[email protected]> wrote:
> #endif
> #define __WARN() warn_on_slowpath(__FILE__, __LINE__)
> #define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
> #else
> #define __WARN_printf(arg...) __WARN()
the easiest way I suppose would be to do
#define __WARN_printf(arg..) do { printk(arg); __WARN(); } while (0)
any obvious problems with this ?
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
* David Miller <[email protected]> wrote:
> > net/dccp/options.c: In function 'dccp_parse_options':
> > net/dccp/options.c:67: warning: 'value' may be used uninitialized in
> > this function
>
> Known issue, not trivial to fix, gcc is just being incredibly silly
> here as it can't see all of the control flow.
i just ran into this - do you have any objection against the patch
below?
Should we have a cleaner annotation perhaps instead of
uninitialized_var()? Something like:
#define __used __attribute__((used))
?
Ingo
---------->
From d917af0bd043eab40d57f79cba9cf7a7b265a205 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Fri, 17 Oct 2008 12:41:30 +0200
Subject: [PATCH] fix warning in net/dccp/options.c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
fix this warning:
net/dccp/options.c: In function ‘dccp_parse_options’:
net/dccp/options.c:67: warning: ‘value’ may be used uninitialized in this function
This is a bogus GCC warning. The compiler does not recognize the relation
between "value" and "mandatory" variables: the code flow can ever reach
the "out_invalid_option:" label if 'mandatory' is set to 1, and when
'mandatory' is non-zero, we'll always have 'value' initialized.
Help out the compiler by annotating the variable.
Signed-off-by: Ingo Molnar <[email protected]>
---
net/dccp/options.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/dccp/options.c b/net/dccp/options.c
index 0809b63..18dcfb9 100644
--- a/net/dccp/options.c
+++ b/net/dccp/options.c
@@ -64,7 +64,7 @@ int dccp_parse_options(struct sock *sk, struct dccp_request_sock *dreq,
(dh->dccph_doff * 4);
struct dccp_options_received *opt_recv = &dp->dccps_options_received;
unsigned char opt, len;
- unsigned char *value;
+ unsigned char *uninitialized_var(value);
u32 elapsed_time;
__be32 opt_val;
int rc;
On Thu, 2008-10-16 at 13:02 -0700, Arjan van de Ven wrote:
> On Thu, 16 Oct 2008 12:49:23 -0700 (PDT)
> David Miller <[email protected]> wrote:
> > #endif
> > #define __WARN() warn_on_slowpath(__FILE__, __LINE__)
> > #define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
> > #else
> > #define __WARN_printf(arg...) __WARN()
>
> the easiest way I suppose would be to do
>
> #define __WARN_printf(arg..) do { printk(arg); __WARN(); } while (0)
>
> any obvious problems with this ?
No, not really. You won't get it on kerneloops, but I guess that's not
an easily tractable problem.
johannes