- 25 Feb, 2018 40 commits
-
-
Arnd Bergmann authored
When CONFIG_ELF_CORE is disabled, we get a harmless warning in the compat version of binfmt_elf: fs/compat_binfmt_elf.c:58:13: error: 'cputime_to_compat_timeval' defined but not used [-Werror=unused-function] This was addressed in mainline Linux as part of a larger rework with commit cd19c364 ("fs/binfmt: Convert obsolete cputime type to nsecs"). For 4.9 and earlier, this just shuts up the warning by adding an #ifdef around the function definition. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
commit 900a9020 upstream. The sunxi clk driver causes a link error when the reset controller subsystem is disabled: drivers/clk/built-in.o: In function `sun4i_ve_clk_setup': :(.init.text+0xd040): undefined reference to `reset_controller_register' drivers/clk/built-in.o: In function `sun4i_a10_display_init': :(.init.text+0xe5e0): undefined reference to `reset_controller_register' drivers/clk/built-in.o: In function `sunxi_usb_clk_setup': :(.init.text+0x10074): undefined reference to `reset_controller_register' We already force it to be enabled on arm32 and some other arm64 platforms, but not on arm64/sunxi. This adds the respective Kconfig statements to also select it here. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> [arnd: manually rebased to 4.9] Signed-off-by:
-
Arnd Bergmann authored
commit fd94d53e upstream. Building i915 without backlight support results in a harmless warning for intel_panel_set_backlight: drivers/gpu/drm/i915/intel_panel.c:653:13: error: 'intel_panel_set_backlight' defined but not used [-Werror=unused-function] This moves it into the CONFIG_BACKLIGHT_CLASS_DEVICE section that its caller is in. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171127151239.1813673-2-arnd@arndb.de [arnd: manually rebased to 4.9] Signed-off-by:
-
Arnd Bergmann authored
commit e7c52b84 upstream. We get a lot of very large stack frames using gcc-7.0.1 with the default -fsanitize-address-use-after-scope --param asan-stack=1 options, which can easily cause an overflow of the kernel stack, e.g. drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes To reduce this risk, -fsanitize-address-use-after-scope is now split out into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack frames that are smaller than 2 kilobytes most of the time on x86_64. An earlier version of this patch also prevented combining KASAN_EXTRA with KASAN_INLINE, but that is no longer necessary with gcc-7.0.1. All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can bring back that default now. KASAN_EXTRA=y still causes lots of warnings but now defaults to !COMPILE_TEST to disable it in allmodconfig, and it remains disabled in all other defconfigs since it is a new option. I arbitrarily raise the warning limit for KASAN_EXTRA to 3072 to reduce the noise, but an allmodconfig kernel still has around 50 warnings on gcc-7. I experimented a bit more with smaller stack frames and have another follow-up series that reduces the warning limit for 64-bit architectures to 1280 bytes (without CONFIG_KASAN). With earlier versions of this patch series, I also had patches to address the warnings we get with KASAN and/or KASAN_EXTRA, using a "noinline_if_stackbloat" annotation. That annotation now got replaced with a gcc-8 bugfix (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for older compilers, which means that KASAN_EXTRA is now just as bad as before and will lead to an instant stack overflow in a few extreme cases. This reverts parts of commit 3f181b4d ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y"). Two patches in linux-next should be merged first to avoid introducing warnings in an allmodconfig build: 3cd890db ("media: dvb-frontends: fix i2c access helpers for KASAN") 16c3ada8 ("media: r820t: fix r820t_write_reg for KASAN") Do we really need to backport this? I think we do: without this patch, enabling KASAN will lead to unavoidable kernel stack overflow in certain device drivers when built with gcc-7 or higher on linux-4.10+ or any version that contains a backport of commit c5caf21a. Most people are probably still on older compilers, but it will get worse over time as they upgrade their distros. The warnings we get on kernels older than this should all be for code that uses dangerously large stack frames, though most of them do not cause an actual stack overflow by themselves.The asan-stack option was added in linux-4.0, and commit 3f181b4d ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y") effectively turned off the warning for allmodconfig kernels, so I would like to see this fix backported to any kernels later than 4.0. I have done dozens of fixes for individual functions with stack frames larger than 2048 bytes with asan-stack, and I plan to make sure that all those fixes make it into the stable kernels as well (most are already there). Part of the complication here is that asan-stack (from 4.0) was originally assumed to always require much larger stacks, but that turned out to be a combination of multiple gcc bugs that we have now worked around and fixed, but sanitize-address-use-after-scope (from v4.10) has a much higher inherent stack usage and also suffers from at least three other problems that we have analyzed but not yet fixed upstream, each of them makes the stack usage more severe than it should be. Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.deSigned-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> [arnd: rebase to v4.9; only re-enable warning] Signed-off-by:
-
Tobias Regnery authored
commit dbed87a9 upstream. With CONFIG_RESET_CONTROLLER=n we see the following link error in the meson gxbb clk driver: drivers/built-in.o: In function 'gxbb_aoclkc_probe': drivers/clk/meson/gxbb-aoclk.c:161: undefined reference to 'devm_reset_controller_register' Fix this by selecting the reset controller subsystem. Fixes: f8c11f79 ("clk: meson: Add GXBB AO Clock and Reset controller driver") Signed-off-by:
Tobias Regnery <tobias.regnery@gmail.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> [narmstrong: Added fixes-by tag] Signed-off-by:
-
Arnd Bergmann authored
commit 27d80718 upstream. I noticed that this function uses a lot of kernel stack when the "latent entropy" plugin is enabled: drivers/isdn/hardware/eicon/message.c: In function 'sig_ind': drivers/isdn/hardware/eicon/message.c:6113:1: error: the frame size of 1168 bytes is larger than 1152 bytes [-Werror=frame-larger-than=] We currently don't warn about this, as we raise the warning limit to 2048 bytes in mainline, but I'd like to lower that limit again in the future, and this function can easily be changed to be more efficient and avoid that warning, by making some of its local variables 'const'. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Arnd Bergmann authored
commit 27430d19 upstream. tw5864_frameinterval_get() only initializes its output when it successfully identifies the video standard in tw5864_input. We get a warning here because gcc can't always track the state if initialized warnings across a WARN() macro, and thinks it might get used incorrectly in tw5864_s_parm: media/pci/tw5864/tw5864-video.c: In function 'tw5864_s_parm': media/pci/tw5864/tw5864-video.c:816:38: error: 'time_base.numerator' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/pci/tw5864/tw5864-video.c:819:31: error: 'time_base.denominator' may be used uninitialized in this function [-Werror=maybe-uninitialized] Using dev_warn() instead of WARN() avoids the __branch_check__() in unlikely and lets the compiler see that the initialization is correct. Signed-off-by:
Andrey Utkin <andrey.utkin@corp.bluecherry.net> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Arnd Bergmann authored
commit 190b23b4 upstream. In randconfig builds that select VIDEO_EM28XX_V4L2 and MEDIA_SUBDRV_AUTOSELECT, but not MEDIA_CAMERA_SUPPORT, we get a Kconfig warning: warning: (VIDEO_EM28XX_V4L2) selects VIDEO_MT9V011 which has unmet direct dependencies (MEDIA_SUPPORT && I2C && VIDEO_V4L2 && MEDIA_CAMERA_SUPPORT) This avoids the warning by making that 'select' conditional on MEDIA_CAMERA_SUPPORT. Alternatively we could mark EM28XX as 'depends on MEDIA_CAMERA_SUPPORT', but it does not seem to have any real dependency on that itself. Signed-off-by:
-
Arnd Bergmann authored
commit fa6317ee upstream. If MEDIA_SUBDRV_AUTOSELECT and VIDEO_GO7007 are both set, we automatically select VIDEO_OV7640, but that depends on MEDIA_CAMERA_SUPPORT, so we get a Kconfig warning if that is disabled: warning: (VIDEO_GO7007) selects VIDEO_OV7640 which has unmet direct dependencies (MEDIA_SUPPORT && I2C && VIDEO_V4L2 && MEDIA_CAMERA_SUPPORT) This adds another dependency so we don't accidentally select it when it is unavailable. Signed-off-by:
-
Arnd Bergmann authored
commit 3538aa6e upstream. While testing with CONFIG_UBSAN, I got this warning: drivers/media/i2c/tc358743.c: In function 'tc358743_probe': drivers/media/i2c/tc358743.c:1930:1: error: the frame size of 2480 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] The problem is that the i2c_rd8/wr8/rd16/... functions in this driver pass a pointer to a local variable into a common function, and each call to one of them adds another variable plus redzone to the stack. I also noticed that the way this is done is broken on big-endian machines, as we copy the registers in CPU byte order. To address both those problems, I'm adding two helper functions for reading a register of up to 32 bits with correct endianess and change all other functions to use that instead. Just to be sure we don't get the problem back with changed optimizations in gcc, I'm also marking the new functions as 'noinline', although my tests with gcc-7 don't require that. Signed-off-by:
-
Jérémy Lefaure authored
commit f1f5929c upstream. Compiling shmem.c with SHMEM and TRANSAPRENT_HUGE_PAGECACHE enabled raises warnings on two unused functions when CONFIG_TMPFS and CONFIG_SYSFS are both disabled: mm/shmem.c:390:20: warning: `shmem_format_huge' defined but not used [-Wunused-function] static const char *shmem_format_huge(int huge) ^~~~~~~~~~~~~~~~~ mm/shmem.c:373:12: warning: `shmem_parse_huge' defined but not used [-Wunused-function] static int shmem_parse_huge(const char *str) ^~~~~~~~~~~~~~~~ A conditional compilation on tmpfs or sysfs removes the warnings. Link: http://lkml.kernel.org/r/20161118055749.11313-1-jeremy.lefaure@lse.epita.frSigned-off-by:
Jérémy Lefaure <jeremy.lefaure@lse.epita.fr> Acked-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
-
Arnd Bergmann authored
commit e42eef4b upstream. The rework of the posted interrupt handling broke building without support for the local APIC: ERROR: "boot_cpu_physical_apicid" [arch/x86/kvm/kvm-intel.ko] undefined! That configuration is probably not particularly useful anyway, so we can avoid the randconfig failures by adding a Kconfig dependency. Fixes: 8b306e2f ("KVM: VMX: avoid double list add with VT-d posted interrupts") Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
commit ea4348c8 upstream. Older versions of gcc warn about the tca8418_irq_handler function as they can't keep track of the variable assignment inside of the loop when using the -Wmaybe-unintialized flag: drivers/input/keyboard/tca8418_keypad.c: In function ‘tca8418_irq_handler’: drivers/input/keyboard/tca8418_keypad.c:172:9: error: ‘reg’ may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/input/keyboard/tca8418_keypad.c:165:5: note: ‘reg’ was declared here This is fixed in gcc-6, but it's possible to rearrange the code in a way that avoids the warning on older compilers as well. Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
commit b74c0a99 upstream. gcc-4.9 notices that the validate_init() function returns unintialized data when called with a zero 'nr_buffers' argument, when called with the -Wmaybe-uninitialized flag: drivers/gpu/drm/nouveau/nouveau_gem.c: In function ‘validate_init.isra.6’: drivers/gpu/drm/nouveau/nouveau_gem.c:457:5: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized] However, the only caller of this function always passes a nonzero argument, and gcc-6 is clever enough to take this into account and not warn about it any more. Adding an explicit initialization to -EINVAL here is correct even if the caller changed, and it avoids the warning on gcc-4.9 as well. Signed-off-by:
Karol Herbst <karolherbst@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Ilya Dryomov authored
commit d4c2269b upstream. drivers/block/rbd.c: In function ‘rbd_watch_cb’: drivers/block/rbd.c:3690:5: error: ‘struct_v’ may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/block/rbd.c:3759:5: note: ‘struct_v’ was declared here Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
commit 7e175100 upstream. The rework of the exynos DRM clock handling introduced warnings for configurations that have CONFIG_PM disabled: drivers/gpu/drm/exynos/exynos_hdmi.c:736:13: error: 'hdmi_clk_disable_gates' defined but not used [-Werror=unused-function] static void hdmi_clk_disable_gates(struct hdmi_context *hdata) ^~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/exynos/exynos_hdmi.c:717:12: error: 'hdmi_clk_enable_gates' defined but not used [-Werror=unused-function] static int hdmi_clk_enable_gates(struct hdmi_context *hdata) The problem is that the PM functions themselves are inside of an #ifdef, but some functions they call are not. This patch removes the #ifdef and instead marks the PM functions as __maybe_unused, which is a more reliable way to get it right. Link: https://patchwork.kernel.org/patch/8436281/ Fixes: 9be7e989 ("drm/exynos/hdmi: clock code re-factoring") Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
-
Arnd Bergmann authored
commit 3cd18d19 upstream. The recent rework introduced a possible randconfig build failure when CONFIG_CRYPTO configured to only allow modules: security/keys/big_key.o: In function `big_key_crypt': big_key.c:(.text+0x29f): undefined reference to `crypto_aead_setkey' security/keys/big_key.o: In function `big_key_init': big_key.c:(.init.text+0x1a): undefined reference to `crypto_alloc_aead' big_key.c:(.init.text+0x45): undefined reference to `crypto_aead_setauthsize' big_key.c:(.init.text+0x77): undefined reference to `crypto_destroy_tfm' crypto/gcm.o: In function `gcm_hash_crypt_remain_continue': gcm.c:(.text+0x167): undefined reference to `crypto_ahash_finup' crypto/gcm.o: In function `crypto_gcm_exit_tfm': gcm.c:(.text+0x847): undefined reference to `crypto_destroy_tfm' When we 'select CRYPTO' like the other users, we always get a configuration that builds. Fixes: 428490e3 ("security/keys: rewrite all of big_key crypto") Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
commit 7fc1503c upstream. On x86, the cw1200 driver produces a rather silly warning about the possible use of the 'ret' variable without an initialization presumably after being confused by the architecture specific definition of WARN_ON: drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’: drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized] We have already checked that 'count' is larger than 0 here, so we know that 'ret' is initialized. Changing the 'for' loop into do/while also makes this clear to the compiler. Suggested-by:
David Laight <David.Laight@ACULAB.COM> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Arnd Bergmann authored
commit ab494964 upstream. The latest gcc-7.0.1 snapshot warns about an unintialized variable use: In file included from fs/reiserfs/lbalance.c:8:0: fs/reiserfs/lbalance.c: In function 'leaf_item_bottle.isra.3': fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)&n_ih+8).v' may be used uninitialized in this function [-Werror=maybe-uninitialized] v2->v = (v2->v & cpu_to_le64(15ULL << 60)) | cpu_to_le64(offset); ~~^~~ fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)&n_ih+8).v' may be used uninitialized in this function [-Werror=maybe-uninitialized] v2->v = (v2->v & cpu_to_le64(15ULL << 60)) | cpu_to_le64(offset); This happens because the offset/type pair that is stored in ih.key.u.k_offset_v2 is actually uninitialized when we call set_le_ih_k_offset() and set_le_ih_k_type(). After we have called both, all data is correct, but the first of the two reads uninitialized data for the type field and writes it back before it gets overwritten. This works around the warning by initializing the k_offset_v2 through the slightly larger memcpy(). [JK: Remove now unused define and make it obvious we initialize the key] Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Arnd Bergmann authored
commit 46a049da upstream. gcc-7 caught what it considers a NULL pointer dereference: sound/pci/hda/patch_ca0132.c: In function 'dspio_scp.constprop': sound/pci/hda/patch_ca0132.c:1487:4: error: argument 1 null where non-null expected [-Werror=nonnull] This is plausible from looking at the function, as we compare 'reply' to NULL earlier in it. I have not tried to analyze if there are constraints that make it impossible to hit the bug, but adding another NULL check in the end kills the warning and makes the function more robust. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kefeng Wang authored
commit 2e449048 upstream. Fix warning: "(COMPAT) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF)" Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Arnd Bergmann authored
commit 44a5b977 upstream. gcc-7.0.1 now warns about a previously unnoticed access of uninitialized struct members: drivers/scsi/advansys.c: In function 'AscMsgOutSDTR': drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized] ((ushort)s_buffer[i + 1] << 8) | s_buffer[i]); ^ drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized] The code has existed in this exact form at least since v2.6.12, and the warning seems correct. This uses named initializers to ensure we initialize all members of the structure. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Kirill A. Shutemov authored
commit 3ba5b5ea upstream. GCC complains about unused variable 'vma' in mark_screen_rdonly() if THP is disabled: arch/x86/kernel/vm86_32.c: In function ‘mark_screen_rdonly’: arch/x86/kernel/vm86_32.c:180:26: warning: unused variable ‘vma’ [-Wunused-variable] struct vm_area_struct *vma = find_vma(mm, 0xA0000); That's silly. pmd_trans_huge() resolves to 0 when THP is disabled, so the whole block should be eliminated. Moving the variable declaration outside the if() block shuts GCC up. Reported-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Tested-by:
Borislav Petkov <bp@suse.de> Cc: Carlos O'Donell <carlos@redhat.com> Link: http://lkml.kernel.org/r/20170213125228.63645-1-kirill.shutemov@linux.intel.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Arnd Bergmann authored
commit d689c64d upstream. The IOSF_MBI option requires PCI support, without it we get a harmless Kconfig warning when it gets selected by PUNIT_ATOM_DEBUG: warning: (X86_INTEL_LPSS && SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG) selects IOSF_MBI which has unmet direct dependencies (PCI) This adds another dependency to avoid the warning. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Jun Nie authored
commit 067fdeb2 upstream. Fix build warning that related to PAGE_SIZE. The maximum DMA length has nothing to do with PAGE_SIZE, just use a fix number for the definition. drivers/dma/zx_dma.c: In function 'zx_dma_prep_memcpy': drivers/dma/zx_dma.c:523:8: warning: division by zero [-Wdiv-by-zero] drivers/dma/zx_dma.c: In function 'zx_dma_prep_slave_sg': drivers/dma/zx_dma.c:567:11: warning: division by zero [-Wdiv-by-zero] Signed-off-by:
Jun Nie <jun.nie@linaro.org> Tested-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Arnd Bergmann authored
commit c2ce3f5d upstream. KVM tries to select 'TASKSTATS', which had additional dependencies: warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET && MULTIUSER) Signed-off-by:
-
Arnd Bergmann authored
commit 68fd77cf upstream. We get a Kconfig warning when selecting this without also enabling CONFIG_PCI: warning: (X86_INTEL_LPSS && INTEL_SOC_DTS_IOSF_CORE && SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG) selects IOSF_MBI which has unmet direct dependencies (PCI) This adds a new depedency. Fixes: 3a2419f8 ("Thermal: Intel SoC: DTS thermal use common APIs") Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Arnd Bergmann authored
commit d460131d upstream. Every kernel build on x86 will result in some output: Setup is 13084 bytes (padded to 13312 bytes). System is 4833 kB CRC 6d35fa35 Kernel: arch/x86/boot/bzImage is ready (#2) This shuts it up, so that 'make -s' is truely silent as long as everything works. Building without '-s' should produce unchanged output. Signed-off-by:
-
Josh Poimboeuf authored
commit e572d088 upstream. When doing a kernel build with 'make -s', everything is silenced except the objtool build. That's because the tools tree support for silent builds is some combination of missing and broken. Three changes are needed to fix it: - Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the tools Makefiles can see it. - tools/scripts/Makefile.include: fix the tools Makefiles' ability to recognize '-s'. The MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences the "DESCEND objtool" message. - tools/build/Makefile.build: add support to the tools Build files for recognizing '-s'. Again the MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences all the object compile/link messages. Reported-and-Tested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Michal Marek <mmarek@suse.com> Link: http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoimboe@redhat.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
commit 75e2f0a6 upstream. When building the kernel with "make EXTRA_CFLAGS=...", this overrides the "PARANOID" preprocessor macro defined in arch/x86/math-emu/Makefile, and we run into a build warning: arch/x86/math-emu/reg_compare.c: In function ‘compare_i_st_st’: arch/x86/math-emu/reg_compare.c:254:6: error: ‘f’ may be used uninitialized in this function [-Werror=maybe-uninitialized] This fixes the implementation to work correctly even without the PARANOID flag, and also fixes the Makefile to not use the EXTRA_CFLAGS variable but instead use the ccflags-y variable in the Makefile that is meant for this purpose. Signed-off-by:
-
Arnd Bergmann authored
commit f13d52cb upstream. This mirrors commit e9c38ceb ("ARM: 8455/1: define __BUG as asm(BUG_INSTR) without CONFIG_BUG") to make the behavior of arm64 consistent with arm and x86, and avoids lots of warnings in randconfig builds, such as: kernel/seccomp.c: In function '__seccomp_filter': kernel/seccomp.c:666:1: error: no return statement in function returning non-void [-Werror=return-type] Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Arnd Bergmann authored
commit b115bebc upstream. When CONFIG_PM_SLEEP is disabled, we get a warning about unused functions: drivers/gpio/gpio-xgene.c:155:12: warning: 'xgene_gpio_resume' defined but not used [-Wunused-function] static int xgene_gpio_resume(struct device *dev) ^~~~~~~~~~~~~~~~~ drivers/gpio/gpio-xgene.c:142:12: warning: 'xgene_gpio_suspend' defined but not used [-Wunused-function] static int xgene_gpio_suspend(struct device *dev) The warnings are harmless and can be avoided by simplifying the code and marking the functions as __maybe_unused. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Borislav Petkov authored
commit d4b2ac63 upstream. ... and get rid of the annoying: arch/x86/kernel/cpu/mcheck/mce-inject.c:97:13: warning: ‘mce_irq_ipi’ defined but not used [-Wunused-function] when doing randconfig builds. Signed-off-by:
-
Arnd Bergmann authored
commit f46e7cd3 upstream. The advansys probe function tries to handle both ISA and PCI cases, each hidden in an #ifdef when unused. This leads to a warning indicating that when PCI is disabled we could be using uninitialized data: drivers/scsi/advansys.c: In function advansys_board_found : drivers/scsi/advansys.c:11036:5: error: ret may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:10928:28: note: ret was declared here drivers/scsi/advansys.c:11309:8: error: share_irq may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:10928:6: note: share_irq was declared here This cannot happen in practice because the hardware in question only exists for PCI, but changing the code to just error out here is better for consistency and avoids the warning. Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
Arnd Bergmann authored
commit 484c7bbf upstream. When CONFIG_PROC_FS is disabled, we get warnings about unused variables as remove_proc_entry() evaluates to an empty macro. drivers/video/fbdev/via/viafbdev.c: In function 'viafb_remove_proc': drivers/video/fbdev/via/viafbdev.c:1635:4: error: unused variable 'iga2_entry' [-Werror=unused-variable] drivers/video/fbdev/via/viafbdev.c:1634:4: error: unused variable 'iga1_entry' [-Werror=unused-variable] These are easy to avoid by using the pointer from the structure. Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Stephen Boyd authored
commit c0bfc549 upstream. I ran into a build error when I disabled CONFIG_ACPI and tried to compile this driver: drivers/perf/xgene_pmu.c:1242:1: warning: data definition has no type or storage class MODULE_DEVICE_TABLE(of, xgene_pmu_of_match); ^ drivers/perf/xgene_pmu.c:1242:1: error: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE' [-Werror=implicit-int] Include module.h for the MODULE_DEVICE_TABLE macro that's implicitly included through ACPI. Tested-by:
Tai Nguyen <ttnguyen@apm.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Marc Gonzalez authored
commit de5bbdd0 upstream. pci_host_common_probe() is defined when CONFIG_PCI_HOST_COMMON=y; therefore the function declaration should match that. drivers/pci/host/pcie-tango.c:300:9: error: implicit declaration of function 'pci_host_common_probe' Signed-off-by:
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Jérémy Lefaure authored
commit c8bd2ac3 upstream. The function musb_run_resume_work is called only when CONFIG_PM is enabled. So this function should not be defined when CONFIG_PM is disabled. Otherwise the compiler issues a warning: drivers/usb/musb/musb_core.c:2057:12: error: ‘musb_run_resume_work’ defined but not used [-Werror=unused-function] static int musb_run_resume_work(struct musb *musb) ^~~~~~~~~~~~~~~~~~~~ Signed-off-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
-
Borislav Petkov authored
commit b4aca383 upstream. Fix: drivers/platform/x86/intel_mid_thermal.c:424:12: warning: ‘mid_thermal_resume’ defined but not used [-Wunused-function] static int mid_thermal_resume(struct device *dev) ^ drivers/platform/x86/intel_mid_thermal.c:436:12: warning: ‘mid_thermal_suspend’ defined but not used [-Wunused-function] static int mid_thermal_suspend(struct device *dev) ^ which I see during randbuilds here. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Augusto Mecking Caringi authored
commit fbc2a294 upstream. The only usage of function intel_gpio_runtime_idle() is here (in the same file): static const struct dev_pm_ops intel_gpio_pm_ops = { SET_RUNTIME_PM_OPS(NULL, NULL, intel_gpio_runtime_idle) }; And when CONFIG_PM is not set, the macro SET_RUNTIME_PM_OPS expands to nothing, causing the following compiler warning: drivers/gpio/gpio-intel-mid.c:324:12: warning: ‘intel_gpio_runtime_idle’ defined but not used [-Wunused-function] static int intel_gpio_runtime_idle(struct device *dev) Fix it by annotating the function with __maybe_unused. Signed-off-by:
Augusto Mecking Caringi <augustocaringi@gmail.com> Acked-by:
-
