summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-09-13Linux 4.1.7v4.1.7Greg Kroah-Hartman
2015-09-13ARM: 8405/1: VDSO: fix regression with toolchains lacking ld.bfd executableNathan Lynch
commit 3473f26592c1c365d376aee29433d7db75f14d1e upstream. The Sourcery CodeBench Lite 2014.05 toolchain (gcc 4.8.3, binutils 2.24.51) has a GCC which implements -fuse-ld, and it doesn't include the gold linker, but it lacks an ld.bfd executable in its installation. This means that passing -fuse-ld=bfd fails with: VDSO arch/arm/vdso/vdso.so.raw collect2: fatal error: cannot find 'ld' Arguably this is a deficiency in the toolchain, but I suspect it's commonly used enough that it's worth accommodating: just use cc-ldoption (to cause a link attempt) instead of cc-option to test whether we can use -fuse-ld. So -fuse-ld=bfd won't be used with this toolchain, but the build will rightly succeed, just as it does for toolchains which don't implement -fuse-ld (and don't use gold as the default linker). Note: this will change the failure mode for a corner case I was trying to handle in d2b30cd4b722, where the toolchain defaults to the gold linker and the BFD linker is not found in PATH, from: VDSO arch/arm/vdso/vdso.so.raw collect2: fatal error: cannot find 'ld' i.e. the BFD linker is not found, to: OBJCOPY arch/arm/vdso/vdso.so BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try linking with -N that is, we fail to prevent gold from being used as the linker, and it produces an object that objcopy can't digest. Reported-by: Baruch Siach <baruch@tkos.co.il> Tested-by: Baruch Siach <baruch@tkos.co.il> Tested-by: Raphaël Poggi <poggi.raph@gmail.com> Fixes: d2b30cd4b722 ("ARM: 8384/1: VDSO: force use of BFD linker") Cc: stable@vger.kernel.org Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13x86/idle: Restore trace_cpu_idle to mwait_idle() callsJisheng Zhang
commit e43d0189ac02415fe4487f79fc35e8f147e9ea0d upstream. Commit b253149b843f ("sched/idle/x86: Restore mwait_idle() to fix boot hangs, to improve power savings and to improve performance") restores mwait_idle(), but the trace_cpu_idle related calls are missing. This causes powertop on my old desktop powered by Intel Core2 E6550 to report zero wakeups and zero events. Add them back to restore the proper behaviour. Fixes: b253149b843f ("sched/idle/x86: Restore mwait_idle() to ...") Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Cc: <len.brown@intel.com> Link: http://lkml.kernel.org/r/1440046479-4262-1-git-send-email-jszhang@marvell.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13x86/apic: Fix fallout from x2apic cleanupThomas Gleixner
commit a57e456a7b28431b55e407e5ab78ebd5b378d19e upstream. In the recent x2apic cleanup I got two things really wrong: 1) The safety check in __disable_x2apic which allows the function to be called unconditionally is backwards. The check is there to prevent access to the apic MSR in case that the machine has no apic. Though right now it returns if the machine has an apic and therefor the disabling of x2apic is never invoked. 2) x2apic_disable() sets x2apic_mode to 0 after registering the local apic. That's wrong, because register_lapic_address() checks x2apic mode and therefor takes the wrong code path. This results in boot failures on machines with x2apic preenabled by BIOS and can also lead to an fatal MSR access on machines without apic. The solutions are simple: 1) Correct the sanity check for apic availability 2) Clear x2apic_mode _before_ calling register_lapic_address() Fixes: 659006bf3ae3 'x86/x2apic: Split enable and setup function' Reported-and-tested-by: Javier Monteagudo <javiermon@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1224764 Cc: Laura Abbott <labbott@redhat.com> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Borislav Petkov <bp@alien8.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13x86/xen: make CONFIG_XEN depend on CONFIG_X86_LOCAL_APICDavid Vrabel
commit 87ffd2b9bb74061c120f450e4d0f3409bb603ae0 upstream. Since commit feb44f1f7a4ac299d1ab1c3606860e70b9b89d69 (x86/xen: Provide a "Xen PV" APIC driver to support >255 VCPUs) Xen guests need a full APIC driver and thus should depend on X86_LOCAL_APIC. This fixes an i386 build failure with !SMP && !CONFIG_X86_UP_APIC by disabling Xen support in this configuration. Users needing Xen support in a non-SMP i386 kernel will need to enable CONFIG_X86_UP_APIC. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13arm64: perf: fix unassigned cpu_pmu->plat_device when probing PMU PPIsShannon Zhao
commit b265da5a45ce60bd3d7505cc0eaa6cfba50946a1 upstream. Commit d795ef9aa831 ("arm64: perf: don't warn about missing interrupt-affinity property for PPIs") added a check for PPIs so that we avoid parsing the interrupt-affinity property for these naturally affine interrupts. Unfortunately, this check can trigger an early (successful) return and we will not assign the value of cpu_pmu->plat_device. This patch fixes the issue. Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13arm64: KVM: Fix host crash when injecting a fault into a 32bit guestMarc Zyngier
commit 126c69a0bd0e441bf6766a5d9bf20de011be9f68 upstream. When injecting a fault into a misbehaving 32bit guest, it seems rather idiotic to also inject a 64bit fault that is only going to corrupt the guest state. This leads to a situation where we perform an illegal exception return at EL2 causing the host to crash instead of killing the guest. Just fix the stupid bug that has been there from day 1. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Tested-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13fnic: Use the local variable instead of I/O flag to acquire io_req_lock in ↵Hiral Shah
fnic_queuecommand() to avoid deadloack commit db196935d9562abec4510f48d887bc1f1e054fcf upstream. We added changes in fnic driver patch 1.6.0.16 to acquire io_req_lock in fnic_queuecommand() before issuing I/O so that io completion is serialized. But when releasing the lock we check for the I/O flag and this could be modified if IO abort occurs before I/O completion. In this case we wont release the lock and causes deadlock in some scenerios. Using the local variable to check the IO lock status will resolve the problem. Fixes: 41df7b02db82cf6c14f094757bac3830d10a827f Signed-off-by: Hiral Shah <hishah@cisco.com> Signed-off-by: Sesidhar Baddela <sebaddel@cisco.com> Signed-off-by: Anil Chintalapati <achintal@cisco.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13Add factory recertified Crucial M500s to blacklistGuillermo A. Amaral
commit 7a7184b01aa9deb86df661c6f7cbcf69a95b728c upstream. The Crucial M500 is known to have issues with queued TRIM commands, the factory recertified SSDs use a different model number naming convention which causes them to get ignored by the blacklist. The new naming convention boils down to: s/Crucial_/FC/ Signed-off-by: Guillermo A. Amaral <g@maral.me> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13can: pcan_usb: don't provide CAN FD bittimings by non-FD adaptersMarc Kleine-Budde
commit 06b23f7fbbf26a025fd68395c7586949db586b47 upstream. The CAN FD data bittiming constants are provided via netlink only when there are valid CAN FD constants available in priv->data_bittiming_const. Due to the indirection of pointer assignments in the peak_usb driver the priv->data_bittiming_const never becomes NULL - not even for non-FD adapters. The data_bittiming_const points to zero'ed data which leads to this result when running 'ip -details link show can0': 35: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10 link/can promiscuity 0 can state STOPPED restart-ms 0 pcan_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1 : dtseg1 0..0 dtseg2 0..0 dsjw 1..0 dbrp 0..0 dbrp-inc 0 <== BROKEN! clock 8000000 This patch changes the struct peak_usb_adapter::bittiming_const and struct peak_usb_adapter::data_bittiming_const to pointers to fix the assignemnt problems. Reported-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13SCSI: Fix NULL pointer dereference in runtime PMAlan Stern
commit 49718f0fb8c9af192b33d8af3a2826db04025371 upstream. The routines in scsi_rpm.c assume that if a runtime-PM callback is invoked for a SCSI device, it can only mean that the device's driver has asked the block layer to handle the runtime power management (by calling blk_pm_runtime_init(), which among other things sets q->dev). However, this assumption turns out to be wrong for things like the ses driver. Normally ses devices are not allowed to do runtime PM, but userspace can override this setting. If this happens, the kernel gets a NULL pointer dereference when blk_post_runtime_resume() tries to use the uninitialized q->dev pointer. This patch fixes the problem by calling the block layer's runtime-PM routines only if the device's driver really does have a runtime-PM callback routine. Since ses doesn't define any such callbacks, the crash won't occur. This fixes Bugzilla #101371. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Stanisław Pitucha <viraptor@gmail.com> Reported-by: Ilan Cohen <ilanco@gmail.com> Tested-by: Ilan Cohen <ilanco@gmail.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13genirq: Introduce irq_chip_set_type_parent() helperGrygorii Strashko
commit b7560de198222994374c1340a389f12d5efb244a upstream. This helper is required for irq chips which do not implement a irq_set_type callback and need to call down the irq domain hierarchy for the actual trigger type change. This helper is required to fix further wreckage caused by the conversion of TI OMAP to hierarchical irq domains and therefor tagged for stable. [ tglx: Massaged changelog ] Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: <linux@arm.linux.org.uk> Cc: <nsekhar@ti.com> Cc: <jason@lakedaemon.net> Cc: <balbi@ti.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: <tony@atomide.com> Cc: <marc.zyngier@arm.com> Cc: stable@vger.kernel.org # 4.1 Link: http://lkml.kernel.org/r/1439554830-19502-3-git-send-email-grygorii.strashko@ti.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13genirq: Don't return ENOSYS in irq_chip_retrigger_hierarchyGrygorii Strashko
commit 6d4affea7d5aa5ca5ff4c3e5fbf3ee16801cc527 upstream. irq_chip_retrigger_hierarchy() returns -ENOSYS if it was not able to find at least one .irq_retrigger() callback implemented in the IRQ domain hierarchy. That's wrong, because check_irq_resend() expects a 0 return value from the callback in case that the hardware assisted resend was not possible. If the return value is non zero the core code assumes hardware resend success and the software resend is not invoked. This results in lost interrupts on platforms where none of the parent irq chips in the hierarchy implements the retrigger callback. This is observable on TI OMAP, where the hierarchy is: ARM GIC <- OMAP wakeupgen <- TI Crossbar Return 0 instead so the software resend mechanism gets invoked. [ tglx: Massaged changelog ] Fixes: 85f08c17de26 ('genirq: Introduce helper functions...') Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Jiang Liu <jiang.liu@linux.intel.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: <linux@arm.linux.org.uk> Cc: <nsekhar@ti.com> Cc: <jason@lakedaemon.net> Cc: <balbi@ti.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: <tony@atomide.com> Link: http://lkml.kernel.org/r/1439554830-19502-2-git-send-email-grygorii.strashko@ti.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanismGrygorii Strashko
commit 63059a272398ef5dc1bd7065a036e8b6e82d1af7 upstream. The conversion of the wakeupgen irqchip to hierarchical irq domains failed to provide a mechanism to properly set the trigger type of an interrupt. The wakeupgen irq chip itself has no mechanism and therefor no irq_set_type() callback. The code before the conversion relayed the trigger configuration directly to the underlying GIC. Restore the correct behaviour by setting the wakeupgen irq_set_type callback to irq_chip_set_type_parent(). This propagates the set_trigger() call to the underlying GIC irqchip. [ tglx: Massaged changelog ] Fixes: 7136d457f365 ('ARM: omap: convert wakeupgen to stacked domains') Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: <linux@arm.linux.org.uk> Cc: <nsekhar@ti.com> Cc: <jason@lakedaemon.net> Cc: <balbi@ti.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: <marc.zyngier@arm.com> Link: http://lkml.kernel.org/r/1439554830-19502-5-git-send-email-grygorii.strashko@ti.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13irqchip/crossbar: Restore set_wake functionalityGrygorii Strashko
commit 8200fe4347870d4ad6475048bcdf3e7c106c5268 upstream. The TI crossbar irqchip doesn't provides any facility to configure the wakeup sources, but the conversion to hierarchical irqdomains set the irq_set_wake callback to irq_chip_set_wake_parent. The parent chip (OMAP wakeupgen) has no irq_set_wake function either so the call will fail with -ENOSYS. As a result the irq_set_wake() call in the resume path will trigger an 'Unbalanced wake disable' warning. Before the conversion the GIC irqchip was the top level irqchip and correctly flagged with IRQCHIP_SKIP_SET_WAKE. Restore the correct behaviour by removing the irq_set_type callback from the crossbar irqchip and set the IRQCHIP_SKIP_SET_WAKE flag which lets the irq_set_irq_wake() call from the driver succeed. [ tglx: Massaged changelog ] Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...') Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: <linux@arm.linux.org.uk> Cc: <nsekhar@ti.com> Cc: <jason@lakedaemon.net> Cc: <balbi@ti.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: <tony@atomide.com> Cc: <marc.zyngier@arm.com> Link: http://lkml.kernel.org/r/1439554830-19502-7-git-send-email-grygorii.strashko@ti.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13irqchip/crossbar: Restore the mask on suspend behaviourGrygorii Strashko
commit 4fd8f47e7e5b64a74b60f23c2e08ba8234d659d1 upstream. The ARM GIC requires that all interrupts which are not used as a wakeup source have to be masked during suspend. The conversion of the crossbar irqchip to hierarchical irq domains failed to mark the crossbar irqchip with the IRQCHIP_MASK_ON_SUSPEND flag and therefor broke the suspend requirement of the GIC. Before the conversion the flags were visible because the GIC was the top level irqchip. After the conversion the crossbar irqchip is the top level irq chip whose flags are evaluated in suspend_device_irq(). As the flag is not set the masking of the non-wakeup irqs is not invoked which breaks suspend. Add the IRQCHIP_MASK_ON_SUSPEND flag to the crossbar irqchip, so the GIC interrupts get masked properly. [ tglx: Massaged changelog ] Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...') Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: <linux@arm.linux.org.uk> Cc: <nsekhar@ti.com> Cc: <jason@lakedaemon.net> Cc: <balbi@ti.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: <tony@atomide.com> Cc: <marc.zyngier@arm.com> Link: http://lkml.kernel.org/r/1439554830-19502-6-git-send-email-grygorii.strashko@ti.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13irqchip/crossbar: Restore the irq_set_type() mechanismGrygorii Strashko
commit e269ec42328783e51be08c191aa935dba56141fc upstream. The conversion of the crossbar irqchip to hierarchical irq domains failed to provide a mechanism to properly set the trigger type of an interrupt. The crossbar irq chip itself has no mechanism and therefor no irq_set_type() callback. The code before the conversion relayed the trigger configuration directly to the underlying GIC. Restore the correct behaviour by setting the crossbar irq_set_type callback to irq_chip_set_type_parent(). This propagates the set_trigger() call to the underlying GIC irqchip. [ tglx: Massaged changelog ] Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...') Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: <linux@arm.linux.org.uk> Cc: <nsekhar@ti.com> Cc: <jason@lakedaemon.net> Cc: <balbi@ti.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: <tony@atomide.com> Cc: <marc.zyngier@arm.com> Link: http://lkml.kernel.org/r/1439554830-19502-4-git-send-email-grygorii.strashko@ti.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-139p: ensure err is initialized to 0 in p9_client_read/writeVincent Bernat
commit 999b8b88c6060adf7a9b7907740ae86ace65291e upstream. Some use of those functions were providing unitialized values to those functions. Notably, when reading 0 bytes from an empty file on a 9P filesystem, the return code of read() was not 0. Tested with this simple program: #include <assert.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> int main(int argc, const char **argv) { assert(argc == 2); char buffer[256]; int fd = open(argv[1], O_RDONLY|O_NOCTTY); assert(fd >= 0); assert(read(fd, buffer, 0) == 0); return 0; } Signed-off-by: Vincent Bernat <vincent@bernat.im> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13drm/i915: Avoid TP3 on CHVThulasimani,Sivakumar
commit ed63baaf849e91c84ac3e042b1fd6a0af07c16f3 upstream. This patch removes TP3 support on CHV since there is no support for HBR2 on this platform. v2: rename the function to indicate it checks source rates (Jani) v3: update comment to indicate TP3 dependency on HBR2 supported hardware (Jani) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> [Jani: fixed a couple of checkpatch warnings.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13drm/i915: remove HBR2 from chv supported listThulasimani,Sivakumar
commit 5e86dfe39f54ab13fd8079ac3d6cb100318909a3 upstream. This patch removes 5.4Gbps from supported link rate for CHV since it is not supported in it. v2: change the ordering for better readability (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13drm/i915: Flag the execlists context object as dirty after every useChris Wilson
commit 903ecd0bb970438c3a60c2c33ec9032d6443bf67 upstream. Everytime we use the logical context with execlists it becomes dirty (as the hardware will write the new register values afterwards, as well as the GPU state that will be used). We need to then flag the context as dirty everytime since after a swap-out/swap-in cycle the dirty flag will be cleared, and a further swap-out cycle will then loose the most recent GPU state. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13drm/atmel-hlcdc: Compile suspend/resume for PM_SLEEP onlyThierry Reding
commit dbb3df2d58754e4df58620e60370d166c2cb6744 upstream. If PM is enabled but PM_SLEEP is disabled, the suspend/resume functions are still unused and produce a compiler warning. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13Input: gpio_keys_polled - request GPIO pin as input.Vincent Pelletier
commit 1ae5ddb6f8837558928a1a694c7b8af7f09fdd21 upstream. GPIOF_IN flag was lost in: Commit 633a21d80b4a("input: gpio_keys_polled: Add support for GPIO descriptors"). Without this flag, legacy code path (for non-descriptor GPIO declarations) would configure GPIO as output (0 meaning GPIOF_DIR_OUT | GPIOF_INIT_LOW). Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13PCI: Don't use 64-bit bus addresses on PA-RISCBjorn Helgaas
commit 45ea2a5fed6dacb9bb0558d8b21eacc1c45d5bb4 upstream. Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t") caused HPMCs on A500 and hangs on rp5470. PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses. After 3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and apparently there's some PA-RISC problem related to them. Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t") Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee Reported-by: Meelis Roos <mroos@linux.ee> Reported-by: Helge Deller <deller@gmx.de> Tested-by: Helge Deller <deller@gmx.de> Based-on-idea-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13target/iscsi: Fix double free of a TUR followed by a solicited NOPOUTAlexei Potashnik
commit 9547308bda296b6f69876c840a0291fcfbeddbb8 upstream. Make sure all non-READ SCSI commands get targ_xfer_tag initialized to 0xffffffff, not just WRITEs. Double-free of a TUR cmd object occurs under the following scenario: 1. TUR received (targ_xfer_tag is uninitialized and left at 0) 2. TUR status sent 3. First unsolicited NOPIN is sent to initiator (gets targ_xfer_tag of 0) 4. NOPOUT for NOPIN (with TTT=0) arrives - its ExpStatSN acks TUR status, TUR is queued for removal - LIO tries to find NOPIN with TTT=0, but finds the same TUR instead, TUR is queued for removal for the 2nd time (Drop unbalanced conditional bracket usage - nab) Signed-off-by: Alexei Potashnik <alexei@purestorage.com> Signed-off-by: Spencer Baugh <sbaugh@catern.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13mac80211: fix invalid read in minstrel_sort_best_tp_rates()Adrien Schildknecht
commit f5eeb5fa191fd7b634cbc4883ac58f3b2184dbc5 upstream. At the last iteration of the loop, j may equal zero and thus tp_list[j - 1] causes an invalid read. Change the logic of the loop so that j - 1 is always >= 0. Signed-off-by: Adrien Schildknecht <adrien+dev@schischi.me> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ALSA: hda: fix possible NULL dereferenceMarkus Osterhoff
commit c7e69ae6b4ff49edf50180c0a32f3dd9d7967e31 upstream. After a for-loop was replaced by list_for_each_entry, see Commit bbbc7e8502c9 ("ALSA: hda - Allocate hda_pcm objects dynamically"), Commit 751e2216899c ("ALSA: hda: fix possible null dereference"), a possible NULL pointer dereference has been introduced; this patch adds the NULL check on pcm->pcm, while leaving a potentially superfluous check on pcm itself untouched. Signed-off-by: Markus Osterhoff <linux-kernel@k-raum.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ALSA: hda - Fix path power activationTakashi Iwai
commit c7cd0ef66aade29e37ee08821a0e195ee776c6e6 upstream. The widget power-saving code tries to turn up/down the power of each widget in the I/O paths that are modified at each jack plug/unplug. The recent report revealed that the power activation leaves some widgets unpowered after plugging. This is because snd_hda_activate_path() turns on path->active flag at the end of the function while the path power management is done before that. Then it's regarded as if nothing is active, and the driver turns off the power. The fix is simply to set the flag at the beginning of the function, before trying to power up. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102521 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ALSA: hda - Check all inputs for is_active_nid_for_any()Takashi Iwai
commit 9d2b48f7304aafaefbf0794a556ab4e307929d24 upstream. The is_active_nid_for_any() function in the generic parser is supposed to check all connections from/to the given widget, but the current code checks only the first input connection (index = 0). This patch corrects the code to check all inputs by passing -1 to index argument. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102521 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ALSA: hda - Shutdown CX20722 on reboot/free to avoid spurious noisesDavid Henningsson
commit f6b28e4ded45bb91bc4cd115d55e35badedfce5f upstream. On shutdown/reboot of CX20722, first shut down all EAPDs, then shut down the afg node to D3. Failure to do so can lead to spurious noises from the internal speaker directly after reboot (and before the codec is reinitialized again, i e in BIOS setup or GRUB menus). BugLink: https://bugs.launchpad.net/bugs/1487345 Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ALSA: usb: Add native DSD support for Gustard DAC-X20UJurgen Kramer
commit 9544f8b6e2ee9ed02d2322ff018837b185f51d45 upstream. This patch adds native DSD support for the Gustard DAC-X20U. Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ALSA: hda - Fix the white noise on Dell laptopWoodrow Shen
commit 7ccb0a9917a511de1d5f92980f26885484d9a914 upstream. Dell laptop causes the white noise by login screen and headphone, and the fixup function ALC292_FIXUP_DISABLE_AAMIX can eliminate this noise. Codec: Realtek ALC3235 Vendor Id: 0x10ec0293 Subsystem Id: 0x102806db BugLink: https://bugs.launchpad.net/bugs/1484334 Signed-off-by: Woodrow Shen <woodrow.shen@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ALSA: usb-audio: Fix runtime PM unbalanceTakashi Iwai
commit 9003ebb13f61e8c78a641e0dda7775183ada0625 upstream. The fix for deadlock in PM in commit [1ee23fe07ee8: ALSA: usb-audio: Fix deadlocks at resuming] introduced a new check of in_pm flag. However, the brainless patch author evaluated it in a wrong way (logical AND instead of logical OR), thus usb_autopm_get_interface() is wrongly called at probing, leading to unbalance of runtime PM refcount. This patch fixes it by correcting the logic. Reported-by: Hans Yang <hansy@nvidia.com> Fixes: 1ee23fe07ee8 ('ALSA: usb-audio: Fix deadlocks at resuming') Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13cpuset: use trialcs->mems_allowed as a temp variableAlban Crequy
commit 24ee3cf89bef04e8bc23788aca4e029a3f0f06d9 upstream. The comment says it's using trialcs->mems_allowed as a temp variable but it didn't match the code. Change the code to match the comment. This fixes an issue when writing in cpuset.mems when a sub-directory exists: we need to write several times for the information to persist: | root@alban:/sys/fs/cgroup/cpuset# mkdir footest9 | root@alban:/sys/fs/cgroup/cpuset# cd footest9 | root@alban:/sys/fs/cgroup/cpuset/footest9# mkdir aa | root@alban:/sys/fs/cgroup/cpuset/footest9# cat cpuset.mems | | root@alban:/sys/fs/cgroup/cpuset/footest9# echo 0 > cpuset.mems | root@alban:/sys/fs/cgroup/cpuset/footest9# cat cpuset.mems | | root@alban:/sys/fs/cgroup/cpuset/footest9# echo 0 > cpuset.mems | root@alban:/sys/fs/cgroup/cpuset/footest9# cat cpuset.mems | 0 | root@alban:/sys/fs/cgroup/cpuset/footest9# cat aa/cpuset.mems | | root@alban:/sys/fs/cgroup/cpuset/footest9# echo 0 > aa/cpuset.mems | root@alban:/sys/fs/cgroup/cpuset/footest9# cat aa/cpuset.mems | 0 | root@alban:/sys/fs/cgroup/cpuset/footest9# This should help to fix the following issue in Docker: https://github.com/opencontainers/runc/issues/133 In some conditions, a Docker container needs to be started twice in order to work. Signed-off-by: Alban Crequy <alban@endocode.com> Tested-by: Iago López Galeiras <iago@endocode.com> Acked-by: Li Zefan <lizefan@huawei.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13Revert "libata: Implement NCQ autosense"Tejun Heo
commit 74a80d67b8316eb3fbeb73dafc060a5a0a708587 upstream. This reverts commit 42b966fbf35da9c87f08d98f9b8978edf9e717cf. As implemented, ACS-4 sense reporting for ATA devices bypasses error diagnosis and handling in libata degrading EH behavior significantly. Revert the related changes for now. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13Revert "libata: Implement support for sense data reporting"Tejun Heo
commit 84ded2f8e7dda336fc2fb3570726ceb3b3b3590f upstream. This reverts commit fe7173c206de63fc28475ee6ae42ff95c05692de. As implemented, ACS-4 sense reporting for ATA devices bypasses error diagnosis and handling in libata degrading EH behavior significantly. Revert the related changes for now. ATA_ID_COMMAND_SET_3/4 constants are not reverted as they're used by later changes. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13Revert "libata-eh: Set 'information' field for autosense"Tejun Heo
commit fe16d4f202c59a560533a223bc6375739ee30944 upstream. This reverts commit a1524f226a02aa6edebd90ae0752e97cfd78b159. As implemented, ACS-4 sense reporting for ATA devices bypasses error diagnosis and handling in libata degrading EH behavior significantly. Revert the related changes for now. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13crypto: caam - fix memory corruption in ahash_final_ctxHoria Geant?
commit b310c178e6d897f82abb9da3af1cd7c02b09f592 upstream. When doing pointer operation for accessing the HW S/G table, a value representing number of entries (and not number of bytes) must be used. Fixes: 045e36780f115 ("crypto: caam - ahash hmac support") Signed-off-by: Horia Geant? <horia.geanta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13crypto: nx - respect sg limit bounds when building sg lists for SHAJan Stancek
commit d3392f41f6d3cd0a034bd0aca47fabea2b47218e upstream. Commit 000851119e80 changed sha256/512 update functions to pass more data to nx_build_sg_list(), which ends with sg list overflows and usually with update functions failing for data larger than max_sg_len * NX_PAGE_SIZE. This happens because: - both "total" and "to_process" are updated, which leads to "to_process" getting overflowed for some data lengths For example: In first iteration "total" is 50, and let's assume "to_process" is 30 due to sg limits. At the end of first iteration "total" is set to 20. At start of 2nd iteration "to_process" overflows on: to_process = total - to_process; - "in_sg" is not reset to nx_ctx->in_sg after each iteration - nx_build_sg_list() is hitting overflow because the amount of data passed to it would require more than sgmax elements - as consequence of previous item, data stored in overflowed sg list may no longer be aligned to SHA*_BLOCK_SIZE This patch changes sha256/512 update functions so that "to_process" respects sg limits and never tries to pass more data to nx_build_sg_list() to avoid overflows. "to_process" is calculated as minimum of "total" and sg limits at start of every iteration. Fixes: 000851119e80 ("crypto: nx - Fix SHA concurrence issue and sg limit bounds") Signed-off-by: Jan Stancek <jstancek@redhat.com> Cc: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com> Cc: Marcelo Henrique Cerri <mhcerri@linux.vnet.ibm.com> Cc: Fionnuala Gunter <fin@linux.vnet.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13sd: Fix maximum I/O size for BLOCK_PC requestsMartin K. Petersen
commit 4f258a46346c03fa0bbb6199ffaf4e1f9f599660 upstream. Commit bcdb247c6b6a ("sd: Limit transfer length") clamped the maximum size of an I/O request to the MAXIMUM TRANSFER LENGTH field in the BLOCK LIMITS VPD. This had the unfortunate effect of also limiting the maximum size of non-filesystem requests sent to the device through sg/bsg. Avoid using blk_queue_max_hw_sectors() and set the max_sectors queue limit directly. Also update the comment in blk_limits_max_hw_sectors() to clarify that max_hw_sectors defines the limit for the I/O controller only. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Reported-by: Brian King <brking@linux.vnet.ibm.com> Tested-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13libiscsi: Fix host busy blocking during connection teardownJohn Soni Jose
commit 660d0831d1494a6837b2f810d08b5be092c1f31d upstream. In case of hw iscsi offload, an host can have N-number of active connections. There can be IO's running on some connections which make host->host_busy always TRUE. Now if logout from a connection is tried then the code gets into an infinite loop as host->host_busy is always TRUE. iscsi_conn_teardown(....) { ......... /* * Block until all in-progress commands for this connection * time out or fail. */ for (;;) { spin_lock_irqsave(session->host->host_lock, flags); if (!atomic_read(&session->host->host_busy)) { /* OK for ERL == 0 */ spin_unlock_irqrestore(session->host->host_lock, flags); break; } spin_unlock_irqrestore(session->host->host_lock, flags); msleep_interruptible(500); iscsi_conn_printk(KERN_INFO, conn, "iscsi conn_destroy(): " "host_busy %d host_failed %d\n", atomic_read(&session->host->host_busy), session->host->host_failed); ................ ............... } } This is not an issue with software-iscsi/iser as each cxn is a separate host. Fix: Acquiring eh_mutex in iscsi_conn_teardown() before setting session->state = ISCSI_STATE_TERMINATE. Signed-off-by: John Soni Jose <sony.john@avagotech.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Chris Leech <cleech@redhat.com> Signed-off-by: James Bottomley <JBottomley@Odin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13MIPS: Fix seccomp syscall argument for MIPS64Markos Chandras
commit 9f161439e4104b641a7bfb9b89581d801159fec8 upstream. Commit 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)") fixed indirect system calls on O32 but it also introduced a bug for MIPS64 where it erroneously modified the v0 (syscall) register with the assumption that the sycall offset hasn't been taken into consideration. This breaks seccomp on MIPS64 n64 and n32 ABIs. We fix this by replacing the addition with a move instruction. Fixes: 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)") Reviewed-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10951/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13regmap: regcache-rbtree: Clean new present bits on present bitmap resizeGuenter Roeck
commit 8ef9724bf9718af81cfc5132253372f79c71b7e2 upstream. When inserting a new register into a block, the present bit map size is increased using krealloc. krealloc does not clear the additionally allocated memory, leaving it filled with random values. Result is that some registers are considered cached even though this is not the case. Fix the problem by clearing the additionally allocated memory. Also, if the bitmap size does not increase, do not reallocate the bitmap at all to reduce overhead. Fixes: 3f4ff561bc88 ("regmap: rbtree: Make cache_present bitmap per node") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13Revert x86 sigcontext cleanupsLinus Torvalds
commit ed596cde9425509ec6ce88e19f03e9b13b6f518b upstream. This reverts commits 9a036b93a344 ("x86/signal/64: Remove 'fs' and 'gs' from sigcontext") and c6f2062935c8 ("x86/signal/64: Fix SS handling for signals delivered to 64-bit programs"). They were cleanups, but they break dosemu by changing the signal return behavior (and removing 'fs' and 'gs' from the sigcontext struct - while not actually changing any behavior - causes build problems). Reported-and-tested-by: Stas Sergeev <stsp@list.ru> Acked-by: Andy Lutomirski <luto@amacapital.net> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13mfd: arizona: Fix initialisation of the PM runtimeCharles Keepax
commit 72e43164fd472f6c2659c8313b87da962322dbcf upstream. The PM runtime core by default assumes a chip is suspended when runtime PM is enabled. Currently the arizona driver enables runtime PM when the chip is fully active and then disables the DCVDD regulator at the end of arizona_dev_init. This however has several problems, firstly the if we reach the end of arizona_dev_init, we did not properly follow all the proceedures for shutting down the chip, and most notably we never marked the chip as cache only so any writes occurring between then and the next PM runtime resume will be lost. Secondly, if we are already resumed when we reach the end of dev_init, then at best we get unbalanced regulator enable/disables at work we lose DCVDD whilst we need it. Additionally, since the commit 4f0216409f7c ("mfd: arizona: Add better support for system suspend"), the PM runtime operations may disable/enable the IRQ, so the IRQs must now be enabled before we call any PM operations. This patch adds a call to pm_runtime_set_active to inform the PM core that the device is starting up active and moves the PM enabling to around the IRQ initialisation to avoid any PM callbacks happening until the IRQs are initialised. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ARM: invalidate L1 before enabling coherencyRussell King
commit bac51ad9d14f6baed3730ef53bedc1eb2238563a upstream. We must invalidate the L1 cache before enabling coherency, otherwise secondary CPUs can inject invalid cache lines into the coherent CPU cluster, which could then be migrated to other CPUs. This fixes a recent regression with SoCFPGA randomly failing to boot. Fixes: 02b4e2756e01 ("ARM: v7 setup function should invalidate L1 cache") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Alexander Kochetkov <al.kochet@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ARM: v7 setup function should invalidate L1 cacheRussell King
commit 02b4e2756e01c623cc4dbceae4b07be75252db5b upstream. All ARMv5 and older CPUs invalidate their caches in the early assembly setup function, prior to enabling the MMU. This is because the L1 cache should not contain any data relevant to the execution of the kernel at this point; all data should have been flushed out to memory. This requirement should also be true for ARMv6 and ARMv7 CPUs - indeed, these typically do not search their caches when caching is disabled (as it needs to be when the MMU is disabled) so this change should be safe. ARMv7 allows there to be CPUs which search their caches while caching is disabled, and it's permitted that the cache is uninitialised at boot; for these, the architecture reference manual requires that an implementation specific code sequence is used immediately after reset to ensure that the cache is placed into a sane state. Such functionality is definitely outside the remit of the Linux kernel, and must be done by the SoC's firmware before _any_ CPU gets to the Linux kernel. Changing the data cache clean+invalidate to a mere invalidate allows us to get rid of a lot of platform specific hacks around this issue for their secondary CPU bringup paths - some of which were buggy. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Dinh Nguyen <dinguyen@opensource.altera.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Michal Simek <michal.simek@xilinx.com> Tested-by: Wei Xu <xuwei5@hisilicon.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Alexander Kochetkov <al.kochet@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ARM: 8384/1: VDSO: force use of BFD linkerNathan Lynch
commit d2b30cd4b7223a96e606dfc8120626f66d81e091 upstream. When using a toolchain with gold as the default linker, the VDSO build fails: VDSO arch/arm/vdso/vdso.so.raw HOSTCC arch/arm/vdso/vdsomunge MUNGE arch/arm/vdso/vdso.so.dbg OBJCOPY arch/arm/vdso/vdso.so BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try linking with -N For whatever reason, ld.gold is omitting an exidx program header that ld.bfd emits, and even when I work around that, I don't get a working VDSO. For now, instead of supporting gold (which will fail to link the kernel anyway since it does not implement --pic-veneer), direct the compiler to use the traditional bfd linker. This is accomplished by using -fuse-ld, which is implemented in GCC 4.8 and later. Note: one limitation of this is that if the toolchain is configured to use gold by default, and the bfd linker is not in $PATH, the VDSO build will fail: VDSO arch/arm/vdso/vdso.so.raw collect2: fatal error: cannot find 'ld' This will happen if CROSS_COMPILE begins with a path such as /opt/bin/arm-linux-gnu- but /opt/bin is not in $PATH. This is considered an acceptable corner-case limitation and is easily worked around. Additonal note: we use cc-option instead of cc-ldoption so that -fuse-ld=bfd is placed in the command line if the compiler recognizes the option. Using cc-ldoption results in an attempt to link, which fails in the situation just described, causing -fuse-ld=bfd to be omitted and gold to be used for the VDSO link, which is what we're trying to prevent. Reported-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Alexander Kochetkov <al.kochet@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ARM: 8385/1: VDSO: group link optionsNathan Lynch
commit d33ce23b2160d26b27a47092da5d556b5b11a12a upstream. Currently the VDSO's link options are kind of a mess spread between ccflags-y and cmd_vdsold. Collect linker directives into one variable, VDSO_LDFLAGS, and use that in cmd_vdsold. Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Alexander Kochetkov <al.kochet@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-13ARM: dts: OMAP5: Fix broken pbias device creationKishon Vijay Abraham I
commit 70caac3f25291cf715cf8f2d8c7db46f6cbefe7c upstream. commit <ed8509edddeb> ("ARM: dts: omap5: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of omap5_padconf_global. After this device for pbias_regulator is not created. Fix it by adding "simple-bus" compatible property to omap5_padconf_global dt node. Fixes: ed8509edddeb ("ARM: dts: omap5: add minimal l4 bus layout with control module support") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-28 08:42:45 +0000