aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-02-10drm/i915: fix error path in intel_setup_gmbus()Rasmus Villemoes1-1/+1
This fails to undo the setup for pin==0; moreover, something interesting happens if the setup failed already at pin==0. Signed-off-by: Rasmus Villemoes <[email protected]> Fixes: f899fc64cda8 ("drm/i915: use GMBUS to manage i2c links") Cc: [email protected] Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2417c8c03f508841b85bf61acc91836b7b0e2560) Signed-off-by: Jani Nikula <[email protected]>
2016-02-10arm64: debug: re-enable irqs before sending breakpoint SIGTRAPWill Deacon1-26/+22
force_sig_info can sleep under an -rt kernel, so attempting to send a breakpoint SIGTRAP with interrupts disabled yields the following BUG: BUG: sleeping function called from invalid context at /kernel-source/kernel/locking/rtmutex.c:917 in_atomic(): 0, irqs_disabled(): 128, pid: 551, name: test.sh CPU: 5 PID: 551 Comm: test.sh Not tainted 4.1.13-rt13 #7 Hardware name: Freescale Layerscape 2085a RDB Board (DT) Call trace: dump_backtrace+0x0/0x128 show_stack+0x24/0x30 dump_stack+0x80/0xa0 ___might_sleep+0x128/0x1a0 rt_spin_lock+0x2c/0x40 force_sig_info+0xcc/0x210 brk_handler.part.2+0x6c/0x80 brk_handler+0xd8/0xe8 do_debug_exception+0x58/0xb8 This patch fixes the problem by ensuring that interrupts are enabled prior to sending the SIGTRAP if they were already enabled in the user context. Reported-by: Yang Shi <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-02-10drm/i915/skl: Fix typo in DPLL_CFGCR1 definitionLyude1-1/+1
We accidentally point both cfgcr registers for the second shared DPLL to the same location in i915_reg.h. This results in a lot of hw pipe state mismatches whenever we try to do a modeset that requires allocating the DPLL to a CRTC: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x80000168, found 0x000004a5) [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 108000, found 49500) [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 108000, found 49500) This usually ends up causing blank monitors, since the DPLL never can get set to the right clock. Fixes: 086f8e84a085 ("drm/i915: Prefix raw register defines with underscore") Signed-off-by: Lyude <[email protected]> Cc: [email protected] Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit da3b891b0fb88605bb2d16adaf1ef2a1f16403ba) Signed-off-by: Jani Nikula <[email protected]>
2016-02-10mmc: sh_mmcif: Correct TX DMA channel allocationChris Paterson1-1/+1
Commit 27cbd7e815a8 ("mmc: sh_mmcif: rework dma channel handling") introduced a typo causing the TX DMA channel allocation to be overwritten by the requested RX DMA channel. Fixes: 27cbd7e815a8 ("mmc: sh_mmcif: rework dma channel handling") Signed-off-by: Chris Paterson <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-02-10drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()Lyude1-1/+2
We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a result we skip assigning a DPLL to any DP MST ports, which makes link training fail: [ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well [ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well [ 1442.933957] [drm:intel_mst_pre_enable_dp] 0 [ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels 00000000 [ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0 [ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 [ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels 05000000 [ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1 [ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1 [ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels 08000000 [ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2 … [ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up [ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting After which the pipe state goes completely out of sync: [ 70.075596] [drm:check_crtc_state] [CRTC:25] [ 70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001) [ 70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0) [ 70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021) [ 70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173) [ 70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5) [ 70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256) [ 70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500) And if you're especially lucky, it keeps going downhill: [ 83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler [ 83.309265] [ 83.309265] ================================= [ 83.309266] [ INFO: inconsistent lock state ] [ 83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted [ 83.309267] --------------------------------- [ 83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes: [ 83.309293] (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915] [ 83.309293] {IN-HARDIRQ-W} state was registered at: [ 83.309297] [<ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00 [ 83.309299] [<ffffffff810ea1be>] lock_acquire+0xce/0x1c0 [ 83.309302] [<ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90 [ 83.309321] [<ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915] [ 83.309332] [<ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915] [ 83.309337] [<ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300 [ 83.309339] [<ffffffff810fdeb9>] handle_irq_event+0x39/0x60 [ 83.309341] [<ffffffff811010b4>] handle_edge_irq+0x74/0x130 [ 83.309344] [<ffffffff81009073>] handle_irq+0x73/0x120 [ 83.309346] [<ffffffff817805f1>] do_IRQ+0x61/0x120 [ 83.309348] [<ffffffff8177e6d6>] ret_from_intr+0x0/0x20 [ 83.309351] [<ffffffff815f5105>] cpuidle_enter_state+0x105/0x330 [ 83.309353] [<ffffffff815f5367>] cpuidle_enter+0x17/0x20 [ 83.309356] [<ffffffff810dbe1a>] call_cpuidle+0x2a/0x50 [ 83.309358] [<ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0 [ 83.309360] [<ffffffff817701da>] rest_init+0x13a/0x140 [ 83.309363] [<ffffffff81f2af8e>] start_kernel+0x475/0x482 [ 83.309365] [<ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c [ 83.309367] [<ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a Fixes: 82d354370189 ("drm/i915/skl: Implementation of SKL DPLL programming") Signed-off-by: Lyude <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 78385cb398748debb7ea2e36d6d2001830c172bc) Signed-off-by: Jani Nikula <[email protected]>
2016-02-10MIPS: Octeon: Update OCTEON_FEATURE_PCIE for Octeon IIIZubair Lutfullah Kakakhel1-1/+2
Currently the driver tries to probe the pci driver and oops. Add CN7XXX to case so that driver probes the pcie driver. Signed-off-by: Zubair Lutfullah Kakakhel <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/12530/ Signed-off-by: Ralf Baechle <[email protected]>
2016-02-10efi: Do variable name validation tests in utf8Peter Jones1-11/+21
Actually translate from ucs2 to utf8 before doing the test, and then test against our other utf8 data, instead of fudging it. Signed-off-by: Peter Jones <[email protected]> Acked-by: Matthew Garrett <[email protected]> Tested-by: Lee, Chun-Yi <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2016-02-10efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad versionPeter Jones2-23/+14
Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming all variable names fit in ASCII. Signed-off-by: Peter Jones <[email protected]> Acked-by: Matthew Garrett <[email protected]> Tested-by: Lee, Chun-Yi <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2016-02-10lib/ucs2_string: Add ucs2 -> utf8 helper functionsPeter Jones2-0/+66
This adds ucs2_utf8size(), which tells us how big our ucs2 string is in bytes, and ucs2_as_utf8, which translates from ucs2 to utf8.. Signed-off-by: Peter Jones <[email protected]> Tested-by: Lee, Chun-Yi <[email protected]> Acked-by: Matthew Garrett <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2016-02-10Merge branch 'ovs-tunnel-mtu'David S. Miller6-22/+87
David Wragg says: ==================== Set a large MTU on ovs-created tunnel devices Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could transmit vxlan packets of any size, constrained only by the ability to send out the resulting packets. 4.3 introduced netdevs corresponding to tunnel vports. These netdevs have an MTU, which limits the size of a packet that can be successfully encapsulated. The default MTU values are low (1500 or less), which is awkwardly small in the context of physical networks supporting jumbo frames, and leads to a conspicuous change in behaviour for userspace. This patch series sets the MTU on openvswitch-created netdevs to be the relevant maximum (i.e. the maximum IP packet size minus any relevant overhead), effectively restoring the behaviour prior to 4.3. Where relevant, the limits on MTU values that can be directly set on the netdevs are also relaxed. Changes in v2: * Extend to all openvswitch tunnel types, i.e. gre and geneve as well * Use IP_MAX_MTU Changes in v3: * Fix block comment style ==================== Signed-off-by: David S. Miller <[email protected]>
2016-02-10vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devicesDavid Wragg6-10/+50
Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could transmit vxlan packets of any size, constrained only by the ability to send out the resulting packets. 4.3 introduced netdevs corresponding to tunnel vports. These netdevs have an MTU, which limits the size of a packet that can be successfully encapsulated. The default MTU values are low (1500 or less), which is awkwardly small in the context of physical networks supporting jumbo frames, and leads to a conspicuous change in behaviour for userspace. Instead, set the MTU on openvswitch-created netdevs to be the relevant maximum (i.e. the maximum IP packet size minus any relevant overhead), effectively restoring the behaviour prior to 4.3. Signed-off-by: David Wragg <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-10geneve: Relax MTU constraintsDavid Wragg1-1/+12
Allow the MTU of geneve devices to be set to large values, in order to exploit underlying networks with larger frame sizes. GENEVE does not have a fixed encapsulation overhead (an openvswitch rule can add variable length options), so there is no relevant maximum MTU to enforce. A maximum of IP_MAX_MTU is used instead. Encapsulated packets that are too big for the underlying network will get dropped on the floor. Signed-off-by: David Wragg <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-10vxlan: Relax MTU constraintsDavid Wragg1-11/+25
Allow the MTU of vxlan devices without an underlying device to be set to larger values (up to a maximum based on IP packet limits and vxlan overhead). Previously, their MTUs could not be set to higher than the conventional ethernet value of 1500. This is a very arbitrary value in the context of vxlan, and prevented vxlan devices from being able to take advantage of jumbo frames etc. The default MTU remains 1500, for compatibility. Signed-off-by: David Wragg <[email protected]> Acked-by: Roopa Prabhu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-02-10gpio: davinci: Fix the number of controllers allocatedLokesh Vutla1-2/+3
Driver only needs to allocate for [ngpio / 32] controllers, as each controller handles 32 gpios. But the current driver allocates for ngpio of which the extra allocated are unused. Fix it be registering only the required number of controllers. Signed-off-by: Lokesh Vutla <[email protected]> Signed-off-by: Keerthy <[email protected]> Reviewed-by: Grygorii Strashko <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-02-10gpio: davinci: Add the missing of-node pointerKeerthy1-1/+1
Currently the first parameter of irq_domain_add_legacy is NULL. irq_find_host function returns NULL when we do not populate the of_node and hence irq_of_parse_and_map call fails whenever we want to request a gpio irq. This fixes the request_irq failures for gpio interrupts. Signed-off-by: Keerthy <[email protected]> Reviewed-by: Grygorii Strashko <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-02-10MIPS: pci-mt7620: Fix return value check in mt7620_pci_probe()Wei Yongjun1-4/+4
In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun <[email protected]> Acked-by: John Crispin <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/12451/ Signed-off-by: Ralf Baechle <[email protected]>
2016-02-10s390/oprofile: fix address range for asynchronous stackHeiko Carstens1-3/+5
git commit dc7ee00d4771 ("s390: lowcore stack pointer offsets") introduced a regression in regard to s390_backtrace(). The stack pointer for the asynchronous stack in the lowcore now has an additional offset applied. This offset needs to be taken into account in the calculation for the low and high address for the stack. This bug was already partially fixed with commit 9cc5c206d9b4 ("s390/dumpstack: fix address ranges for asynchronous and panic stack"). This patch fixes it also for the oprofile code. Fixes: dc7ee00d4771 ("s390: lowcore stack pointer offsets") Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-02-10s390/perf_event: fix address range for asynchronous stackHeiko Carstens1-3/+5
git commit dc7ee00d4771 ("s390: lowcore stack pointer offsets") introduced a regression in regard to perf_callchain_kernel(). The stack pointer for the asynchronous stack in the lowcore now has an additional offset applied. This offset needs to be taken into account in the calculation for the low and high address for the stack. This bug was already partially fixed with 9cc5c206d9b4 ("s390/dumpstack: fix address ranges for asynchronous and panic stack"). This patch fixes it also for the perf_event code. Fixes: dc7ee00d4771 ("s390: lowcore stack pointer offsets") Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-02-10s390/stacktrace: add save_stack_trace_regs()Pratyush Anand1-0/+11
Implement save_stack_trace_regs, so that a stack trace of a kprobe event can be obtained. Without this we see following warning: "save_stack_trace_regs() not implemented yet." when we execute: echo stacktrace > /sys/kernel/debug/tracing/trace_options echo "p kfree" >> /sys/kernel/debug/tracing/kprobe_events echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable Reported-by: Chunyu Hu <[email protected]> Signed-off-by: Pratyush Anand <[email protected]> [[email protected]]: changed patch to use __save_stack_trace() Signed-off-by: Heiko Carstens <[email protected]> Tested-by: Peter Oberparleiter <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-02-10s390/stacktrace: save full stack tracesHeiko Carstens1-9/+12
save_stack_trace() only saves the stack trace of the current context (interrupt or process context). This is different to what other architectures like x86 do, which save the full stack trace across different contexts. Also extract a __save_stack_trace() helper function which will be used by a follow on patch. Signed-off-by: Heiko Carstens <[email protected]> Tested-by: Peter Oberparleiter <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-02-10s390/stacktrace: add missing end markerHeiko Carstens1-0/+2
save_stack_trace() did not write the ULONG_MAX end marker if there is enough space left. So simply follow x86 and arm64. Signed-off-by: Heiko Carstens <[email protected]> Tested-by: Peter Oberparleiter <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-02-10s390/stacktrace: fix address ranges for asynchronous and panic stackHeiko Carstens1-5/+6
git commit dc7ee00d4771 ("s390: lowcore stack pointer offsets") introduced a regression in regard to save_stack_trace(). The stack pointer for the asynchronous and the panic stack in the lowcore now have an additional offset applied to them. This offset needs to be taken into account in the calculation for the low and high address for the stacks. This bug was already partially fixed with 9cc5c206d9b4 ("s390/dumpstack: fix address ranges for asynchronous and panic stack"). This patch fixes it also for the stacktrace code. Fixes: dc7ee00d4771 ("s390: lowcore stack pointer offsets") Signed-off-by: Heiko Carstens <[email protected]> Tested-by: Peter Oberparleiter <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-02-10s390/stacktrace: fix save_stack_trace_tsk() for current taskHeiko Carstens1-0/+4
The function save_stack_trace_tsk() did not consider that it can be used for tsk == current, for which the current stack pointer obviously cannot be found in the thread structure. Fix this and get the stack pointer with an inline assembly. This fixes e.g. the output of "cat /proc/self/stack". Before: [<0000000000000000>] (null) [<ffffffffffffffff>] 0xffffffffffffffff After: [<000000000011b3ee>] save_stack_trace_tsk+0x56/0x98 [<0000000000366cde>] proc_pid_stack+0xae/0x108 [<00000000003636f0>] proc_single_show+0x70/0xc0 [<0000000000311fbc>] seq_read+0xcc/0x448 [<00000000002e7716>] __vfs_read+0x36/0x100 [<00000000002e872e>] vfs_read+0x76/0x130 [<00000000002e975e>] SyS_read+0x66/0xd8 [<000000000089490e>] system_call+0xd6/0x264 [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by: Heiko Carstens <[email protected]> Tested-by: Peter Oberparleiter <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2016-02-10mmc: block: return error on failed mmc_blk_get()Olof Johansson1-1/+3
This used to return -EFAULT, but the function above returns -EINVAL on the same condition so let's stick to that. The removal of error return on this path was introduced with b093410c9aef ('mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD'). Fixes: b093410c9aef ('mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD'). Signed-off-by: Olof Johansson <[email protected]> Cc: Grant Grundler <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-02-10spi: bcm2835aux: fix bitmask definesStephan Olbrich1-2/+2
The bitmasks for txempty and idle interrupts were interchanged. Signed-off-by: Stephan Olbrich <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2016-02-10phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reloadTony Lindgren1-5/+8
If we reload phy-twl4030-usb, we get a warning about unbalanced pm_runtime_enable. Let's fix the issue and also fix idling of the device on unload before we attempt to shut it down. If we don't properly idle the PHY before shutting it down on removal, the twl4030 ends up consuming about 62mW of extra power compared to running idle with the module loaded. Cc: [email protected] Cc: Bin Liu <[email protected]> Cc: Felipe Balbi <[email protected]> Cc: Kishon Vijay Abraham I <[email protected]> Cc: NeilBrown <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Kishon Vijay Abraham I <[email protected]>
2016-02-10phy: twl4030-usb: Relase usb phy on unloadTony Lindgren1-0/+1
Otherwise rmmod omap2430; rmmod phy-twl4030-usb; modprobe omap2430 will try to use a non-existing phy and oops: Unable to handle kernel paging request at virtual address b6f7c1f0 ... [<c048a284>] (devm_usb_get_phy_by_node) from [<bf0758ac>] (omap2430_musb_init+0x44/0x2b4 [omap2430]) [<bf0758ac>] (omap2430_musb_init [omap2430]) from [<bf055ec0>] (musb_init_controller+0x194/0x878 [musb_hdrc]) Cc: [email protected] Cc: Bin Liu <[email protected]> Cc: Felipe Balbi <[email protected]> Cc: Kishon Vijay Abraham I <[email protected]> Cc: NeilBrown <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Kishon Vijay Abraham I <[email protected]>
2016-02-10phy: core: fix wrong err handle for phy_power_onShawn Lin1-7/+9
If phy_pm_runtime_get_sync failed but we already enable regulator, current code return directly without doing regulator_disable. This patch fix this problem and cleanup err handle of phy_power_on to be more readable. Fixes: 3be88125d85d ("phy: core: Support regulator ...") Cc: <[email protected]> # v3.18+ Cc: Roger Quadros <[email protected]> Cc: Axel Lin <[email protected]> Signed-off-by: Shawn Lin <[email protected]> Signed-off-by: Kishon Vijay Abraham I <[email protected]>
2016-02-09SCSI: Add Marvell configuration device to VPD blacklistTodd Fujinaka1-0/+1
The Marvell 91xx configuration device also needs to be on the VPD blacklist. [mkp: Match all revisions] Signed-off-by: Todd Fujinaka <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2016-02-10ARCv2: intc: Allow interruption by lowest priority interruptVineet Gupta2-19/+29
ARC HS Cores support configurable multiple interrupt priorities of upto 16 levels. There is processor "interrupt preemption threshhold" in STATUS32.E[4:1] And several places need to set this up: 1. seed value as kernel is booting 2. seed value for user space programs 3. Arg to SLEEP instruction in idle task (what interrupt prio can wake) 4. Per-IRQ line prioirty (i.e. what is the priority of interrupt raised by a peripheral or timer or perf counter... Currently above sites use the highest priority 0. This can be potential problem when multiple priorities are supported. e.g. user space could only be interrupted by P0 interrupt, not others... So turn this over and instead make default interruption level to be the lowest priority possible 15. This should be fine even if there are fewer priority levels configured (say two: P0 HIGH, P1 LOW) This feature also effectively disables FIRQ feature if present in hardware config. With old code, a P0 interrupt would be FIRQ, needing special handling (ISR or Register Banks) which is NOT supported yet. Now it not be P0 (P15 or whatever is lowest prio) so FIRQ is not triggered. Signed-off-by: Vineet Gupta <[email protected]>
2016-02-09Merge tag 'fixes-for-linus' of ↵Linus Torvalds2-54/+85
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux Pull module fixes from Rusty Russell: "Fix for async_probe module param added in 4.3 (clearly not widely used yet), and a much more interesting kallsyms race which has been around approximately forever. This fix is more invasive, and will require some care in backporting, but I hated all the bandaids I could think of, so... There are some more coming, which are only for breakages introduced this cycle (livepatch), but wanted these in now" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: modules: fix longstanding /proc/kallsyms vs module insertion race. module: wrapper for symbol name. modules: fix modparam async_probe request
2016-02-09Input: colibri-vf50-ts - add missing #include <linux/of.h>Geert Uytterhoeven1-0/+1
drivers/input/touchscreen/colibri-vf50-ts.c: In function ‘vf50_ts_probe’: drivers/input/touchscreen/colibri-vf50-ts.c:302: error: implicit declaration of function ‘of_property_read_u32’ Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2016-02-09Input: adp5589 - fix row 5 handling for adp5589Lars-Peter Clausen1-3/+4
The adp5589 has row 5, don't skip it when creating the GPIO mapping. Otherwise the pin gets reserved as used and it is not possible to use it as a GPIO. Signed-off-by: Lars-Peter Clausen <[email protected]> Acked-by: Michael Hennerich <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2016-02-09Input: edt-ft5x06 - fix setting gain, offset, and threshold via device treePhilipp Zabel1-6/+12
A recent patch broke parsing the gain, offset, and threshold parameters from device tree. Instead of setting the cached values and writing them to the correct registers during probe, it would write the values from DT into the register address variables and never write them to the chip during normal operation. Fixes: 2e23b7a96372 ("Input: edt-ft5x06 - use generic properties API") Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2016-02-09workqueue: implement "workqueue.debug_force_rr_cpu" debug featureTejun Heo3-2/+47
Workqueue used to guarantee local execution for work items queued without explicit target CPU. The guarantee is gone now which can break some usages in subtle ways. To flush out those cases, this patch implements a debug feature which forces round-robin CPU selection for all such work items. The debug feature defaults to off and can be enabled with a kernel parameter. The default can be flipped with a debug config option. If you hit this commit during bisection, please refer to 041bd12e272c ("Revert "workqueue: make sure delayed work run in local cpu"") for more information and ping me. Signed-off-by: Tejun Heo <[email protected]>
2016-02-09workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUsMike Galbraith1-2/+32
WORK_CPU_UNBOUND work items queued to a bound workqueue always run locally. This is a good thing normally, but not when the user has asked us to keep unbound work away from certain CPUs. Round robin these to wq_unbound_cpumask CPUs instead, as perturbation avoidance trumps performance. tj: Cosmetic and comment changes. WARN_ON_ONCE() dropped from empty (wq_unbound_cpumask AND cpu_online_mask). If we want that, it should be done when config changes. Signed-off-by: Mike Galbraith <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2016-02-09thermal: allow u8500-thermal driver to be a moduleArnd Bergmann2-2/+5
When the thermal subsystem is a loadable module, the u8500 driver fails to build: drivers/thermal/built-in.o: In function `db8500_thermal_probe': db8500_thermal.c:(.text+0x96c): undefined reference to `thermal_zone_device_register' drivers/thermal/built-in.o: In function `db8500_thermal_work': db8500_thermal.c:(.text+0xab4): undefined reference to `thermal_zone_device_update' This changes the symbol to a tristate, so Kconfig can track the dependency correctly. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2016-02-09thermal: allow spear-thermal driver to be a moduleArnd Bergmann1-1/+1
When the thermal subsystem is a loadable module, the spear driver fails to build: drivers/thermal/built-in.o: In function `spear_thermal_exit': spear_thermal.c:(.text+0xf8): undefined reference to `thermal_zone_device_unregister' drivers/thermal/built-in.o: In function `spear_thermal_probe': spear_thermal.c:(.text+0x230): undefined reference to `thermal_zone_device_register' This changes the symbol to a tristate, so Kconfig can track the dependency correctly. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2016-02-09thermal: spear: use __maybe_unused for PM functionsArnd Bergmann1-4/+2
The spear thermal driver hides its suspend/resume function conditionally based on CONFIG_PM, but references them based on CONFIG_PM_SLEEP, so we get a warning if the former is set but the latter is not: thermal/spear_thermal.c:58:12: warning: 'spear_thermal_suspend' defined but not used [-Wunused-function] thermal/spear_thermal.c:75:12: warning: 'spear_thermal_resume' defined but not used [-Wunused-function] This removes the #ifdef and instead uses a __maybe_uninitialized annotation to avoid the warning and improve compile-time coverage. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2016-02-09Merge branch 'topic/core-fixes' into for-linusTakashi Iwai704-56920/+7198
2016-02-09thermal: rcar: enable to use thermal-zone on DTKuninori Morimoto2-7/+75
This patch enables to use thermal-zone on DT if it was calles as "renesas,rcar-thermal-gen2". Previous style (= non thermal-zone) is still supported by "renesas,rcar-thermal" to keep compatibility for "git bisect". Signed-off-by: Kuninori Morimoto <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2016-02-09thermal: of: use for_each_available_child_of_node for child iteratorLaxman Dewangan1-15/+3
Use for_each_available_child_of_node() for iterating over each available child instead of iterating over each child and then checking their status. Signed-off-by: Laxman Dewangan <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2016-02-09Revert "workqueue: make sure delayed work run in local cpu"Tejun Heo1-4/+4
This reverts commit 874bbfe600a660cba9c776b3957b1ce393151b76. Workqueue used to implicity guarantee that work items queued without explicit CPU specified are put on the local CPU. Recent changes in timer broke the guarantee and led to vmstat breakage which was fixed by 176bed1de5bf ("vmstat: explicitly schedule per-cpu work on the CPU we need it to run on"). vmstat is the most likely to expose the issue and it's quite possible that there are other similar problems which are a lot more difficult to trigger. As a preventive measure, 874bbfe600a6 ("workqueue: make sure delayed work run in local cpu") was applied to restore the local CPU guarnatee. Unfortunately, the change exposed a bug in timer code which got fixed by 22b886dd1018 ("timers: Use proper base migration in add_timer_on()"). Due to code restructuring, the commit couldn't be backported beyond certain point and stable kernels which only had 874bbfe600a6 started crashing. The local CPU guarantee was accidental more than anything else and we want to get rid of it anyway. As, with the vmstat case fixed, 874bbfe600a6 is causing more problems than it's fixing, it has been decided to take the chance and officially break the guarantee by reverting the commit. A debug feature will be added to force foreign CPU assignment to expose cases relying on the guarantee and fixes for the individual cases will be backported to stable as necessary. Signed-off-by: Tejun Heo <[email protected]> Fixes: 874bbfe600a6 ("workqueue: make sure delayed work run in local cpu") Link: http://lkml.kernel.org/g/[email protected] Cc: [email protected] Cc: Mike Galbraith <[email protected]> Cc: Henrique de Moraes Holschuh <[email protected]> Cc: Daniel Bilik <[email protected]> Cc: Jan Kara <[email protected]> Cc: Shaohua Li <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Ben Hutchings <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Daniel Bilik <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: Michal Hocko <[email protected]>
2016-02-09block: fix module reference leak on put_disk() call for cgroups throttleRoman Pen1-0/+9
get_disk(),get_gendisk() calls have non explicit side effect: they increase the reference on the disk owner module. The following is the correct sequence how to get a disk reference and to put it: disk = get_gendisk(...); /* use disk */ owner = disk->fops->owner; put_disk(disk); module_put(owner); fs/block_dev.c is aware of this required module_put() call, but f.e. blkg_conf_finish(), which is located in block/blk-cgroup.c, does not put a module reference. To see a leakage in action cgroups throttle config can be used. In the following script I'm removing throttle for /dev/ram0 (actually this is NOP, because throttle was never set for this device): # lsmod | grep brd brd 5175 0 # i=100; while [ $i -gt 0 ]; do echo "1:0 0" > \ /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device; i=$(($i - 1)); \ done # lsmod | grep brd brd 5175 100 Now brd module has 100 references. The issue is fixed by calling module_put() just right away put_disk(). Signed-off-by: Roman Pen <[email protected]> Cc: Gi-Oh Kim <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Jens Axboe <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Jens Axboe <[email protected]>
2016-02-09Merge branch 'linus' of ↵Linus Torvalds4-51/+60
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes the following issues: API: - Fix async algif_skcipher, it was broken by recent fixes. - Fix potential race condition in algif_skcipher with ctx. - Fix potential memory corruption in algif_skcipher. - Add missing lock to crypto_user when doing an alg dump. Drivers: - marvell/cesa was testing the wrong variable for NULL after allocation. - Fix potential double-free in atmel-sha. - Fix illegal call to sleepin function from atomic context in atmel-sha" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: marvell/cesa - fix test in mv_cesa_dev_dma_init() crypto: atmel-sha - remove calls of clk_prepare() from atomic contexts crypto: atmel-sha - fix atmel_sha_remove() crypto: algif_skcipher - Do not set MAY_BACKLOG on the async path crypto: algif_skcipher - Do not dereference ctx without socket lock crypto: algif_skcipher - Do not assume that req is unchanged crypto: user - lock crypto_alg_list on alg dump
2016-02-09scripts: add "prune-kernel" script to clean up old kernel imagesJ. Bruce Fields1-0/+20
Long ago, Dave Jones complained about CONFIG_LOCALVERSION_AUTO: "I don't use the auto config, because I end up filling up /boot unless I go through and clean them out by hand every time I install a new one (which I do probably a dozen or so times a day). Is there some easy way to prune old builds I'm missing?" To which Bruce replied: "I run this by hand every now and then. I'm probably doing it all wrong" And if he is running it wrong, then so am I - because I've been using this script ever since. It is true that CONFIG_LOCALVERSION_AUTO easily ends up filling your /boot partition if you don't clean up old versions regularly, and this script helps make that easier. Checked with Bruce to see that it's fine to add this to the kernel scripts. Maybe people will come up with enhancements, but more importantly, this way I won't misplace this script whenever I install a new machine and start doing custom kernels for it. Signed-off-by: Linus Torvalds <[email protected]>
2016-02-09arm64: disable kasan when accessing frame->fp in unwind_frameYang Shi1-2/+2
When boot arm64 kernel with KASAN enabled, the below error is reported by kasan: BUG: KASAN: out-of-bounds in unwind_frame+0xec/0x260 at addr ffffffc064d57ba0 Read of size 8 by task pidof/499 page:ffffffbdc39355c0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() page dumped because: kasan: bad access detected CPU: 2 PID: 499 Comm: pidof Not tainted 4.5.0-rc1 #119 Hardware name: Freescale Layerscape 2085a RDB Board (DT) Call trace: [<ffffffc00008d078>] dump_backtrace+0x0/0x290 [<ffffffc00008d32c>] show_stack+0x24/0x30 [<ffffffc0006a981c>] dump_stack+0x8c/0xd8 [<ffffffc0002e4400>] kasan_report_error+0x558/0x588 [<ffffffc0002e4958>] kasan_report+0x60/0x70 [<ffffffc0002e3188>] __asan_load8+0x60/0x78 [<ffffffc00008c92c>] unwind_frame+0xec/0x260 [<ffffffc000087e60>] get_wchan+0x110/0x160 [<ffffffc0003b647c>] do_task_stat+0xb44/0xb68 [<ffffffc0003b7730>] proc_tgid_stat+0x40/0x50 [<ffffffc0003ac840>] proc_single_show+0x88/0xd8 [<ffffffc000345be8>] seq_read+0x370/0x770 [<ffffffc00030aba0>] __vfs_read+0xc8/0x1d8 [<ffffffc00030c0ec>] vfs_read+0x94/0x168 [<ffffffc00030d458>] SyS_read+0xb8/0x128 [<ffffffc000086530>] el0_svc_naked+0x24/0x28 Memory state around the buggy address: ffffffc064d57a80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4 ffffffc064d57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc064d57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ffffffc064d57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc064d57c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Since the shadow byte pointed by the report is 0, so it may mean it is just hit oob in non-current task. So, disable the instrumentation to silence these warnings. Acked-by: Andrey Ryabinin <[email protected]> Signed-off-by: Yang Shi <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-02-09nvme: fix Kconfig description for BLK_DEV_NVME_SCSIChristoph Hellwig1-2/+3
Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2016-02-09kernel/fs: fix I/O wait not accounted for RW O_DSYNCStephane Gasparini1-1/+1
When a process is doing Random Write with O_DSYNC flag the I/O wait are not accounted in the kernel (get_cpu_iowait_time_us). This is preventing the governor or the cpufreq driver to account for I/O wait and thus use the right pstate Signed-off-by: Stephane Gasparini <[email protected]> Signed-off-by: Philippe Longepe <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2016-02-09MIPS: Fix early CM probingPaul Burton3-18/+1
Commit c014d164f21d ("MIPS: Add platform callback before initializing the L2 cache") added a platform_early_l2_init function in order to allow platforms to probe for the CM before L2 initialisation is performed, so that CM GCRs are available to mips_sc_probe. That commit actually fails to do anything useful, since it checks mips_cm_revision to determine whether it should call mips_cm_probe but the result of mips_cm_revision will always be 0 until mips_cm_probe has been called. Thus the "early" mips_cm_probe call never occurs. Fix this & drop the useless weak platform_early_l2_init function by simply calling mips_cm_probe from setup_arch. For platforms that don't select CONFIG_MIPS_CM this will be a no-op, and for those that do it removes the requirement for them to call mips_cm_probe manually (although doing so isn't harmful for now). Signed-off-by: Paul Burton <[email protected]> Reviewed-by: Alexander Sverdlin <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Aaro Koskinen <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Rob Herring <[email protected]> Cc: Peter Hurley <[email protected]> Cc: Leonid Yegoshin <[email protected]> Cc: Jaedon Shin <[email protected]> Cc: James Hogan <[email protected]> Cc: Jonas Gorski <[email protected]> Cc: Markos Chandras <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/12475/ Signed-off-by: Ralf Baechle <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.