- 15 May, 2014 30 commits
-
-
Alexander Usyskin authored
commit 34ec4366 upstream. Ignore client writing state during cb completion to fix a memory leak. When moving cbs to the completion list we should not look at writing_state as this state can be already overwritten by next write, the fact that a cb is on the write waiting list means that it was already written to the HW and we can safely complete it. Same pays for wait in poll handler, we do not have to check the state wake is done after completion list processing. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Tomas Winkler authored
commit 5e6533a6 upstream. NM and SPS FW types that may run on ME device on server platforms do not have valid MEI/HECI interface and driver should not be bound to it as this might lead to system hung. In practice not all BIOSes effectively hide such devices from the OS and in some cases it is not possible. We determine FW type by examining Host FW status registers in order to unbind the driver. In this patch we are adding check for ME on Cougar Point, Lynx Point Devices Signed-off-by:
Nikola Ciprich <nikola.ciprich@linuxbox.cz> Signed-off-by:
-
Tomas Winkler authored
commit cc99ecfd upstream. Write callbacks are released on the write completed path but when file handler is closed before the writes are completed those are left dangling on write and write_waiting queues. We add mei_io_list_free function to perform this task Also move static functions to client.c form client.h Signed-off-by:
-
Christian Borntraeger authored
commit 2955c83f upstream. Since commit 7c470539 (s390/kvm: avoid automatic sie reentry) we will run through the C code of KVM on host interrupts instead of just reentering the guest. This will result in additional ucontrol exits (at least HZ per second). Let handle a 0 intercept in the kernel and dont return to userspace, even if in ucontrol mode. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
-
Sebastian Ott authored
commit 2253e8d7 upstream. ccw consoles are in use before they can be properly registered with the driver core. For devices which are in use by a device driver we rely on the ccw_device's pointer to the driver callbacks to be valid. For ccw consoles this pointer is NULL until they are registered later during boot and we dereferenced this pointer. This worked by chance on 64 bit builds (cdev->drv was NULL but the optional callback cdev->drv->path_event was also NULL by coincidence) and was unnoticed until we received reports about boot failures on 31 bit systems. Fix it by initializing the driver pointer for ccw consoles. Reported-by:
Mike Frysinger <vapier@gentoo.org> Reported-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Reviewed-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Uwe Kleine-König authored
commit 12f6dd86 upstream. Wolfram Sang pointed out that "efm32,$device" is non-standard. So use the common scheme and prefix device with "efm32-". The old compatible string is left in place until arch/arm/boot/dts/efm32* is fixed. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Lv Zheng authored
commit 61db45ca upstream. The original code was lost accidently, it was not generated along with the following commit of mechanism improvements and thus not get merged: Commit: d5a36100 Subject: ACPICA: Add mechanism for early object repairs on a per-name basis Adds the framework to allow object repairs very early in the return object analysis. Enables repairs like string->unicode, etc. This patch restores the implementation of the NULL element repair code for ACPI_RTYPE_NONE. In the original design, ACPI_RTYPE_NONE is defined to collect simple NULL object repairs. Lv Zheng. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=67901Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Kailang Yang authored
commit 8dc9abb9 upstream. Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kailang Yang authored
commit 7c665932 upstream. Signed-off-by:
-
Takashi Iwai authored
commit 415d555e upstream. The recent fixups for HP laptops to support the mute LED made the speaker output silent on some machines. It turned out that they use the NID 0x18 for the speaker while it's also used for controlling the LED via VREF bits although the current driver code blindly assumes that such a node is a mic pin (where 0x18 is usually so). This patch fixes the problem by only changing the VREF bits and keeping the other pin ctl bits. Reported-and-tested-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
Takashi Iwai authored
commit 4f8e9400 upstream. PCM pointer callbacks in ice1712 driver check the buffer size boundary wrongly between bytes and frames. This leads to PCM core warnings like: snd_pcm_update_hw_ptr0: 105 callbacks suppressed ALSA pcm_lib.c:352 BUG: pcmC3D0c:0, pos = 5461, buffer size = 5461, period size = 2730 This patch fixes these checks to be placed after the proper unit conversions. Signed-off-by:
-
W. Trevor King authored
commit a4b7f21d upstream. The `lspci -nnvv` output contains (wrapped for line length): 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) Subsystem: ASUSTeK Computer Inc. Device [1043:115d] Signed-off-by:
W. Trevor King <wking@tremily.us> Signed-off-by:
-
Thomas Petazzoni authored
commit a6e03dd4 upstream. The mvmdio driver accesses some register of the Ethernet unit. It therefore takes a reference and enables a clock. However, on Armada 370/XP, no clock specification was given in the Device Tree, which leads the mvmdio driver to fail when being used as a module and loaded before the mvneta driver: it tries to access a register from a hardware unit that isn't clocked. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1395790439-21332-2-git-send-email-thomas.petazzoni@free-electrons.comAcked-by:
Andrew Lunn <andrew@lunn.ch> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Liu Hua authored
commit 56b700fd upstream. For vmcore generated by LPAE enabled kernel, user space utility such as crash needs additional infomation to parse. So this patch add arch_crash_save_vmcoreinfo as what PAE enabled i386 linux does. Reviewed-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Liu Hua <sdu.liu@huawei.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Xiangyu Lu authored
commit 80bb3ef1 upstream. In big-endian systems, "%1" get the most significant part of the value, cause the instruction to get the wrong result. When viewing ftrace record in big-endian ARM systems, we found that the timestamp errors: swapper-0 [001] 1325.970000: 0:120:R ==> [001] 16:120:R events/1 events/1-16 [001] 1325.970000: 16:120:S ==> [001] 0:120:R swapper swapper-0 [000] 1325.1000000: 0:120:R + [000] 15:120:R events/0 swapper-0 [000] 1325.1000000: 0:120:R ==> [000] 15:120:R events/0 swapper-0 [000] 1326.030000: 0:120:R + [000] 1150:120:R sshd swapper-0 [000] 1326.030000: 0:120:R ==> [000] 1150:120:R sshd When viewed ftrace records, it will call the do_div(n, base) function, which achieved arch/arm/include/asm/div64.h in. When n = 10000000, base = 1000000, in do_div(n, base) will execute "umull %Q0, %R0, %1, %Q2". Reviewed-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
Alex Wu <wuquanming@huawei.com> Signed-off-by:
Xiangyu Lu <luxiangyu@huawei.com> Signed-off-by:
-
Christopher Covington authored
commit 95c52fe0 upstream. The kcmp system call was ported to ARM in commit 3f7d1fe1 "ARM: 7665/1: Wire up kcmp syscall". Fixes: 3f7d1fe1 ("ARM: 7665/1: Wire up kcmp syscall") Signed-off-by:
Christopher Covington <cov@codeaurora.org> Signed-off-by:
-
Andrew Lunn authored
commit 12567bbd upstream. CPU_ARM926T should be selected if no other CPU is. Put the ! in the right place so this works. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Tested-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Fixes: 24e860fb ("ARM: multiplatform: always pick one CPU type") Signed-off-by:
-
Will Deacon authored
commit b6ccb980 upstream. CPU_32v6 currently selects CPU_USE_DOMAINS if CPU_V6 and MMU. This is because ARM 1136 r0pX CPUs lack the v6k extensions, and therefore do not have hardware thread registers. The lack of these registers requires the kernel to update the vectors page at each context switch in order to write a new TLS pointer. This write must be done via the userspace mapping, since aliasing caches can lead to expensive flushing when using kmap. Finally, this requires the vectors page to be mapped r/w for kernel and r/o for user, which has implications for things like put_user which must trigger CoW appropriately when targetting user pages. The upshot of all this is that a v6/v7 kernel makes use of domains to segregate kernel and user memory accesses. This has the nasty side-effect of making device mappings executable, which has been observed to cause subtle bugs on recent cores (e.g. Cortex-A15 performing a speculative instruction fetch from the GIC and acking an interrupt in the process). This patch solves this problem by removing the remaining domain support from ARMv6. A new memory type is added specifically for the vectors page which allows that page (and only that page) to be mapped as user r/o, kernel r/w. All other user r/o pages are mapped also as kernel r/o. Patch co-developed with Russell King. Signed-off-by:
-
Tomasz Figa authored
commit bfeda827 upstream. Apparently, if G3D regulator is powered off, the SoC cannot enter low power modes and just hangs. This patch fixes this by keeping the regulator always on when the system is running, as suggested by Exynos 4 User's Manual in case of Exynos4210/4x12 SoCs (Exynos5250 UM does not have such note, but observed behavior seems to confirm that it is true for this SoC as well). This fixes an issue preventing Arndale board from entering sleep mode observed since commit 346f372f clk: exynos5250: Add CLK_IGNORE_UNUSED flag for pmu clock that landed in kernel 3.10, which has fixed the clock driver to make the SoC actually try to enter the sleep mode. Signed-off-by:
Tomasz Figa <t.figa@samsung.com> Acked-by:
Kyungmin Park <kyungmin.park@samsung.com> Tested-by:
Tushar Behera <tushar.behera@linaro.org> Signed-off-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Mugunthan V N authored
commit 8abcdd68 upstream. DT node's unit address should be its own register offset address to make it a unique across the system. This patch corrects the incorrect USB entries with correct register offset for unit address. Acked-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Roger Quadros authored
commit c6c56697 upstream. OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the proper clock domains for USB Host and USB TLL modules. Gets rid of the following warnings during boot omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm Reported-by:
Nishanth Menon <nm@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Fixes: de231388 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3") Cc: Keshava Munegowda <keshava_mgowda@ti.com> Cc: Partha Basak <parthab@india.ti.com> Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Nishanth Menon authored
commit 07484ca3 upstream. Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if CONFIG_PM is enabled, else, disabling CONFIG_PM results in build failure complaining about the following: arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary': :(.text+0x8a70): undefined reference to `pm44xx_errata' Fixes: c9621844 (ARM: OMAP4: PM: add errata support) Reported-by:
Santosh Shilimkar <santosh.shilimkar@ti.ocm> Acked-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
-
Stefan Sørensen authored
commit 698b4853 upstream. When an interrupt has become active on the INTC it will stay active until it is acked, even if masked or de-asserted. The INTC_PENDING_IRQn registers are however updated and since these are used by omap_intc_handle_irq to determine which interrupt to handle, it will never see the active interrupt. This will result in a storm of useless interrupts that is only stopped when another higher priority interrupt is asserted. Fix by sending the INTC an acknowledge if we find no interrupts to handle. Signed-off-by:
Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by:
-
Brian Austin authored
commit 1555b652 upstream. The mask bits values were wrong for the SOC_VALUE_ENUM_SINGLE for the mono mix controls. Reported-by:
Brian Austin <brian.austin@cirrus.com> Signed-off-by:
-
Brian Austin authored
commit d31a33dd upstream. The mask bits values were wrong for the SOC_VALUE_ENUM_SINGLE for the PCM/ADC Swap controls Reported-by:
-
Brian Austin authored
commit 7272e051 upstream. The shift values for the ADC,PCM, and Analog kcontrols were wrong causing wrong values for the SOC_DOUBLE_R_SX_TLV macros Fixed the TLV for aout_tlv to show -102dB correctly Fixes: 1d99f243 (ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV) Reported-by:
-
Catalin Marinas authored
commit de2db743 upstream. pgprot_{dmacoherent,writecombine,noncached} don't need to generate executable mappings with side-effects like __sync_icache_dcache() being called when the mapping is in user space. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Reported-by:
Bharat Bhushan <Bharat.Bhushan@freescale.com> Tested-by:
Laura Abbott <lauraa@codeaurora.org> Tested-by:
-
Catalin Marinas authored
commit 71fdb6bf upstream. Special pte mappings are not intended to be executable and do not even have an associated struct page. This patch ensures that we do not call __sync_icache_dcache() on such ptes. Signed-off-by:
Steve Capper <Steve.Capper@arm.com> Tested-by:
-
K. Y. Srinivasan authored
commit 03367ef5 upstream. Only ws2012r2 hosts support the ability to reconnect to the host on VMBUS. This functionality is needed by kexec in Linux. To use this functionality we need to negotiate version 3.0 of the VMBUS protocol. This patch has been backported to apply against the 3.12 stable tree. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> [3.9+] Signed-off-by:
-
K. Y. Srinivasan authored
commit e28bab48 upstream. During the initial VMBUS connect phase, starting with WS2012 R2, we should specify the VPCU in the guest that should receive the notification. Fix this issue. This fix is required to properly connect to the host in the kexeced kernel. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
- 09 May, 2014 2 commits
-
-
Nicholas Bellinger authored
commit 03e7848a upstream. This patch fixes a bug where outstanding RDMA_READs with WRITE_PENDING status require an extra target_put_sess_cmd() in isert_put_cmd() code when called from isert_cq_tx_comp_err() + isert_cq_drain_comp_llist() context during session shutdown. The extra kref PUT is required so that transport_generic_free_cmd() invokes the last target_put_sess_cmd() -> target_release_cmd_kref(), which will complete(&se_cmd->cmd_wait_comp) the outstanding se_cmd descriptor with WRITE_PENDING status, and awake the completion in target_wait_for_sess_cmds() to invoke TFO->release_cmd(). The bug was manifesting itself in target_wait_for_sess_cmds() where a se_cmd descriptor with WRITE_PENDING status would end up sleeping indefinately. (Fix up v3.12.y context changes - nab) Acked-by:
Sagi Grimberg <sagig@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: <stable@vger.kernel.org> #3.10+ Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
commit f46d6a8a upstream. This patch changes isert_conn_create_fastreg_pool() to follow logic in iscsi_target_locate_portal() for determining how many FRMR descriptors to allocate based upon the number of possible per-session command slots that are available. This addresses an OOPs in isert_reg_rdma() where due to the use of ISCSI_DEF_XMIT_CMDS_MAX could end up returning a bogus fast_reg_descriptor when the number of active tags exceeded the original hardcoded max. Note this also includes moving isert_conn_create_fastreg_pool() from isert_connect_request() to isert_put_login_tx() before posting the final Login Response PDU in order to determine the se_nacl->queue_depth (eg: number of tags) per session the target will be enforcing. v2 changes: - Move isert_conn->conn_fr_pool list_head init into isert_conn_request() v3 changes: - Drop unnecessary list_empty() check in isert_reg_rdma() (Sagi) (Fix up v3.12.y context changes - nab) Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: <stable@vger.kernel.org> #3.12+ Signed-off-by:
-
- 05 May, 2014 8 commits
-
-
Hui Wang authored
commit 493a52a9 upstream. On some AIO (All In One) models with the codec alc668 (Vendor ID: 0x10ec0668) on it, when we plug a headphone into the jack, the system will switch the output to headphone and set the speaker to automute as well as change the speaker Pin-ctls from 0x40 to 0x00, this will bring loud noise to the headphone. I tried to disable the corresponding EAPD, but it did not help to eliminate the noise. According to Takashi's suggestion, we use amp operation to replace the pinctl modification for the automute, this really eliminate the noise. BugLink: https://bugs.launchpad.net/bugs/1268468 Cc: David Henningsson <david.henningsson@canonical.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Bart Van Assche authored
commit a97f4a66 upstream. When dlm_release_lockspace(ls, 1) is invoked on a busy system immediately after the last dlm_unlock() AST has finished it can occur that lkb_idr_is_local() is invoked for the unlocked LKB since removal from ls_lkbidr only occurs after the AST has returned. If that happens dlm_release_lockspace(ls, 1) will return -EBUSY instead of releasing the lockspace. Fix this race condition by changing lkb_idr_is_local() such that it only returns true for LKB's that have not yet been unlocked. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
David Teigland <teigland@redhat.com> Signed-off-by:
-
Jiri Slaby authored
-
Oleg Nesterov authored
commit c39df5fa upstream. Commit 8aac6270 ("move exit_task_namespaces() outside of exit_notify()") breaks pppd and the exiting service crashes the kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: ppp_register_channel+0x13/0x20 [ppp_generic] Call Trace: ppp_asynctty_open+0x12b/0x170 [ppp_async] tty_ldisc_open.isra.2+0x27/0x60 tty_ldisc_hangup+0x1e3/0x220 __tty_hangup+0x2c4/0x440 disassociate_ctty+0x61/0x270 do_exit+0x7f2/0xa50 ppp_register_channel() needs ->net_ns and current->nsproxy == NULL. Move disassociate_ctty() before exit_task_namespaces(), it doesn't make sense to delay it after perf_event_exit_task() or cgroup_exit(). This also allows to use task_work_add() inside the (nontrivial) code paths in disassociate_ctty(). Investigated by Peter Hurley. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
Sree Harsha Totakura <sreeharsha@totakura.in> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Sree Harsha Totakura <sreeharsha@totakura.in> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Jeff Dike <jdike@addtoit.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andrey Vagin <avagin@openvz.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Oleg Nesterov authored
commit dfccbb5e upstream. wait_task_zombie() first does EXIT_ZOMBIE->EXIT_DEAD transition and drops tasklist_lock. If this task is not the natural child and it is traced, we change its state back to EXIT_ZOMBIE for ->real_parent. The last transition is racy, this is even documented in 50b8d257 "ptrace: partially fix the do_wait(WEXITED) vs EXIT_DEAD->EXIT_ZOMBIE race". wait_consider_task() tries to detect this transition and clear ->notask_error but we can't rely on ptrace_reparented(), debugger can exit and do ptrace_unlink() before its sub-thread sets EXIT_ZOMBIE. And there is another problem which were missed before: this transition can also race with reparent_leader() which doesn't reset >exit_signal if EXIT_DEAD, assuming that this task must be reaped by someone else. So the tracee can be re-parented with ->exit_signal != SIGCHLD, and if /sbin/init doesn't use __WALL it becomes unreapable. Change reparent_leader() to update ->exit_signal even if EXIT_DEAD. Note: this is the simple temporary hack for -stable, it doesn't try to solve all problems, it will be reverted by the next changes. Signed-off-by:
Jan Kratochvil <jan.kratochvil@redhat.com> Reported-by:
Michal Schmidt <mschmidt@redhat.com> Tested-by:
-
David S. Miller authored
[ Upstream commit cb3042d6 ] In arch_cpu_idle() we must enable %pil based interrupts before potentially invoking the hypervisor cpu yield call. As per the Hypervisor API documentation for cpu_yield: Interrupts which are blocked by some mechanism other that pstate.ie (for example %pil) are not guaranteed to cause a return from this service. It seems that only first generation Niagara chips are hit by this bug. My best guess is that later chips implement this in hardware and wake up anyways from %pil events, whereas in first generation chips the yield is implemented completely in hypervisor code and requires %pil to be enabled in order to wake properly from this call. Fixes: 87fa05ae ("sparc: Use generic idle loop") Reported-by:
Fabio M. Di Nitto <fabbione@fabbione.net> Reported-by:
Jan Engelhardt <jengelh@inai.de> Tested-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Dave Kleikamp authored
[ Upstream commit 1535bd8a ] When checking a system call return code for an error, linux_sparc_syscall was sign-extending the lower 32-bit value and comparing it to -ERESTART_RESTARTBLOCK. lseek can return valid return codes whose lower 32-bits alone would indicate a failure (such as 4G-1). Use the whole 64-bit value to check for errors. Only the 32-bit path should sign extend the lower 32-bit value. Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Acked-by:
Bob Picco <bob.picco@oracle.com> Acked-by:
Allen Pais <allen.pais@oracle.com> Cc: David S. Miller <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Signed-off-by:
-
Paul Gortmaker authored
[ Upstream commit 4f6500ff ] In arch/sparc/Kernel/Makefile, we see: obj-$(CONFIG_SPARC64) += jump_label.o However, the Kconfig selects HAVE_ARCH_JUMP_LABEL unconditionally for all SPARC. This in turn leads to the following failure when doing allmodconfig coverage builds: kernel/built-in.o: In function `__jump_label_update': jump_label.c:(.text+0x8560c): undefined reference to `arch_jump_label_transform' kernel/built-in.o: In function `arch_jump_label_transform_static': (.text+0x85cf4): undefined reference to `arch_jump_label_transform' make: *** [vmlinux] Error 1 Change HAVE_ARCH_JUMP_LABEL to be conditional on SPARC64 so that it matches the Makefile. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
