summaryrefslogtreecommitdiff
path: root/arch/x86/lib/memmove_64.S
diff options
context:
space:
mode:
authorBorislav Petkov <bp@suse.de>2013-03-05 00:16:20 +0400
committerH. Peter Anvin <hpa@linux.intel.com>2013-04-03 03:03:34 +0400
commit73f460408ca9b6e917f32c89c9a85c586f17f732 (patch)
tree925c4d98b4a310b09cca9c0475a70e5a14224bb3 /arch/x86/lib/memmove_64.S
parent1423bed239415edd1562c25be8a7408858fdbb19 (diff)
downloadlinux-73f460408ca9b6e917f32c89c9a85c586f17f732.tar.xz
x86, quirks: Shut-up a long-standing gcc warning
So gcc nags about those since forever in randconfig builds. arch/x86/kernel/quirks.c: In function ‘ati_ixp4x0_rev’: arch/x86/kernel/quirks.c:361:4: warning: ‘b’ is used uninitialized in this function [-Wuninitialized] arch/x86/kernel/quirks.c: In function ‘ati_force_enable_hpet’: arch/x86/kernel/quirks.c:367:4: warning: ‘d’ may be used uninitialized in this function [-Wuninitialized] arch/x86/kernel/quirks.c:357:6: note: ‘d’ was declared here arch/x86/kernel/quirks.c:407:21: warning: ‘val’ may be used uninitialized in this function [-Wuninitialized] This function quirk is called on a SB400 chipset only anyway so the distant possibility of a PCI access failing becomes almost impossible there. Even if it did fail, then something else more serious is the problem. So zero-out the variables so that gcc shuts up but do a coarse check on the PCI accesses at the end and signal whether any of them had an error. They shouldn't but in case they do, we'll at least know and we can address it. Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/1362428180-8865-6-git-send-email-bp@alien8.de Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Diffstat (limited to 'arch/x86/lib/memmove_64.S')
0 files changed, 0 insertions, 0 deletions