1. 03 Sep, 2014 10 commits
  2. 02 Sep, 2014 2 commits
    • Jiri Kosina's avatar
      Revert "leds: convert blink timer to workqueue" · 9067359f
      Jiri Kosina authored
      This reverts commit 8b37e1be.
      
      It's broken as it changes led_blink_set() in a way that it can now sleep
      (while synchronously waiting for workqueue to be cancelled). That's a
      problem, because it's possible that this function gets called from atomic
      context (tpt_trig_timer() takes a readlock and thus disables preemption).
      
      This has been brought up 3 weeks ago already [1] but no proper fix has
      materialized, and I keep seeing the problem since 3.17-rc1.
      
      [1] https://lkml.org/lkml/2014/8/16/128
      
       BUG: sleeping function called from invalid context at kernel/workqueue.c:2650
       in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant
       5 locks held by wpa_supplicant/2335:
        #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff814c7c92>] rtnl_lock+0x12/0x20
        #1:  (&wdev->mtx){+.+.+.}, at: [<ffffffffc06e649c>] cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211]
        #2:  (&local->mtx){+.+.+.}, at: [<ffffffffc0817dea>] ieee80211_prep_connection+0x17a/0x9a0 [mac80211]
        #3:  (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffc08081ed>] ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211]
        #4:  (&trig->leddev_list_lock){.+.+..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211]
       CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1
       Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
        ffff8800360b5a50 ffff8800751f76d8 ffffffff8159e97f ffff8800360b5a30
        ffff8800751f76e8 ffffffff810739a5 ffff8800751f77b0 ffffffff8106862f
        ffffffff810685d0 0aa2209200000000 ffff880000000004 ffff8800361c59d0
       Call Trace:
        [<ffffffff8159e97f>] dump_stack+0x4d/0x66
        [<ffffffff810739a5>] __might_sleep+0xe5/0x120
        [<ffffffff8106862f>] flush_work+0x5f/0x270
        [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80
        [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90
        [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100
        [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
        [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100
        [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10
        [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40
        [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211]
        [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
        [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
        [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211]
        [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
        [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
        [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
        [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
        [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
        [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211]
        [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
        [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211]
        [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211]
        [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211]
        [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211]
        [<ffffffffc06e36c0>] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
        [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211]
        [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0
        [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
        [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0
        [<ffffffff81584fa0>] ? ioctl_standard_iw_point+0x3e0/0x3e0
        [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100
        [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0
        [<ffffffff814cfb29>] dev_ioctl+0x329/0x620
        [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
        [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0
        [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520
        [<ffffffff815a67fb>] ? sysret_check+0x1b/0x56
        [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
        [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0
        [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f
       wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3)
       wlan0: authenticated
       wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3)
       wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2)
       wlan0: associated
       IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
       cfg80211: Calling CRDA for country: NA
       wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by 00:0b:6b:3c:8c:e4
      
       =================================
       [ INFO: inconsistent lock state ]
       3.17.0-rc3 #1 Not tainted
       ---------------------------------
       inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
       swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
        ((&(&led_cdev->blink_work)->work)){+.?...}, at: [<ffffffff810685d0>] flush_work+0x0/0x270
       {SOFTIRQ-ON-W} state was registered at:
         [<ffffffff81094dbe>] __lock_acquire+0x30e/0x1a30
         [<ffffffff81096c81>] lock_acquire+0x91/0x110
         [<ffffffff81068608>] flush_work+0x38/0x270
         [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100
         [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10
         [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40
         [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211]
         [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
         [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
         [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211]
         [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
         [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
         [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
         [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
         [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
         [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211]
         [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
         [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211]
         [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211]
         [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211]
         [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211]
         [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211]
         [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0
         [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0
         [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100
         [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0
         [<ffffffff814cfb29>] dev_ioctl+0x329/0x620
         [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0
         [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520
         [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0
         [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f
       irq event stamp: 493416
       hardirqs last  enabled at (493416): [<ffffffff81068a5f>] __cancel_work_timer+0x6f/0x100
       hardirqs last disabled at (493415): [<ffffffff81067e9f>] try_to_grab_pending+0x1f/0x160
       softirqs last  enabled at (493408): [<ffffffff81053ced>] _local_bh_enable+0x1d/0x50
       softirqs last disabled at (493409): [<ffffffff81054c75>] irq_exit+0xa5/0xb0
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock((&(&led_cdev->blink_work)->work));
         <Interrupt>
           lock((&(&led_cdev->blink_work)->work));
      
        *** DEADLOCK ***
      
       2 locks held by swapper/0/0:
        #0:  (((&tpt_trig->timer))){+.-...}, at: [<ffffffff810b4c50>] call_timer_fn+0x0/0x180
        #1:  (&trig->leddev_list_lock){.+.?..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211]
      
       stack backtrace:
       CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc3 #1
       Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
        ffffffff8246eb30 ffff88007c203b00 ffffffff8159e97f ffffffff81a194c0
        ffff88007c203b50 ffffffff81599c29 0000000000000001 ffffffff00000001
        ffff880000000000 0000000000000006 ffffffff81a194c0 ffffffff81093ad0
       Call Trace:
        <IRQ>  [<ffffffff8159e97f>] dump_stack+0x4d/0x66
        [<ffffffff81599c29>] print_usage_bug+0x1f4/0x205
        [<ffffffff81093ad0>] ? check_usage_backwards+0x140/0x140
        [<ffffffff810944d3>] mark_lock+0x223/0x2b0
        [<ffffffff81094d60>] __lock_acquire+0x2b0/0x1a30
        [<ffffffff81096c81>] lock_acquire+0x91/0x110
        [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80
        [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
        [<ffffffff81068608>] flush_work+0x38/0x270
        [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80
        [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90
        [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100
        [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
        [<ffffffff8109469d>] ? trace_hardirqs_on_caller+0xad/0x1c0
        [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
        [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100
        [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10
        [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40
        [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211]
        [<ffffffff810b4cc5>] call_timer_fn+0x75/0x180
        [<ffffffff810b4c50>] ? process_timeout+0x10/0x10
        [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
        [<ffffffff810b50ac>] run_timer_softirq+0x1fc/0x2f0
        [<ffffffff81054805>] __do_softirq+0x115/0x2e0
        [<ffffffff81054c75>] irq_exit+0xa5/0xb0
        [<ffffffff810049b3>] do_IRQ+0x53/0xf0
        [<ffffffff815a74af>] common_interrupt+0x6f/0x6f
        <EOI>  [<ffffffff8147b56e>] ? cpuidle_enter_state+0x6e/0x180
        [<ffffffff8147b732>] cpuidle_enter+0x12/0x20
        [<ffffffff8108bba0>] cpu_startup_entry+0x330/0x360
        [<ffffffff8158fb51>] rest_init+0xc1/0xd0
        [<ffffffff8158fa90>] ? csum_partial_copy_generic+0x170/0x170
        [<ffffffff81af3ff2>] start_kernel+0x44f/0x45a
        [<ffffffff81af399c>] ? set_init_arg+0x53/0x53
        [<ffffffff81af35ad>] x86_64_start_reservations+0x2a/0x2c
        [<ffffffff81af36a0>] x86_64_start_kernel+0xf1/0xf4
      
      Cc: Vincent Donnefort <vdonnefort@gmail.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarBryan Wu <cooloney@gmail.com>
      9067359f
    • Chao Yu's avatar
      f2fs: reposition unlock_new_inode to prevent accessing invalid inode · b73e5282
      Chao Yu authored
      As the race condition on the inode cache, following scenario can appear:
      [Thread a]				[Thread b]
      					->f2fs_mkdir
      					  ->f2fs_add_link
      					    ->__f2fs_add_link
      					      ->init_inode_metadata failed here
      ->gc_thread_func
        ->f2fs_gc
          ->do_garbage_collect
            ->gc_data_segment
              ->f2fs_iget
                ->iget_locked
                  ->wait_on_inode
      					  ->unlock_new_inode
              ->move_data_page
      					  ->make_bad_inode
      					  ->iput
      
      When we fail in create/symlink/mkdir/mknod/tmpfile, the new allocated inode
      should be set as bad to avoid being accessed by other thread. But in above
      scenario, it allows f2fs to access the invalid inode before this inode was set
      as bad.
      This patch fix the potential problem, and this issue was found by code review.
      
      change log from v1:
       o Add condition judgment in gc_data_segment() suggested by Changman Lee.
       o use iget_failed to simplify code.
      Signed-off-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      b73e5282
  3. 01 Sep, 2014 8 commits
    • Linus Torvalds's avatar
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 7505ceaf
      Linus Torvalds authored
      Pull irq handling fixlet from Thomas Gleixner:
       "Just an export for an interrupt flow handler which is now used in gpio
        modules"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irq: Export handle_fasteoi_irq
      7505ceaf
    • Will Deacon's avatar
      Revert "arm64: cpuinfo: print info for all CPUs" · 5e39977e
      Will Deacon authored
      It turns out that vendors are relying on the format of /proc/cpuinfo,
      and we've even spotted out-of-tree hacks attempting to make it look
      identical to the format used by arch/arm/. That means we can't afford to
      churn this interface in mainline, so revert the recent reformatting of
      the file for arm64 pending discussions on the list to find out what
      people actually want.
      
      This reverts commit d7a49086.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5e39977e
    • Leo Yan's avatar
      arm64: fix bug for reloading FPSIMD state after cpu power off · 7c68a9cc
      Leo Yan authored
      Now arm64 defers reloading FPSIMD state, but this optimization also
      introduces the bug after cpu resume back from low power mode.
      
      The reason is after the cpu has been powered off, s/w need set the
      cpu's fpsimd_last_state to NULL so that it will force to reload
      FPSIMD state for the thread, otherwise there has the chance to meet
      the condition for both the task's fpsimd_state.cpu field contains the
      id of the current cpu, and the cpu's fpsimd_last_state per-cpu variable
      points to the task's fpsimd_state, so finally kernel will skip to reload
      the context during it return back to userland.
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarLeo Yan <leoy@marvell.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      7c68a9cc
    • Linus Torvalds's avatar
      Linux 3.17-rc3 · 69e273c0
      Linus Torvalds authored
      69e273c0
    • Linus Torvalds's avatar
      Merge tag 'xtensa-20140830' of git://github.com/czankel/xtensa-linux · 05bdb8c9
      Linus Torvalds authored
      Pull Xtensa updates from Chris Zankel:
       "Xtensa improvements for 3.17:
         - support highmem on cores with aliasing data cache.  Enable highmem
           on kc705 by default
         - simplify addition of new core variants (no need to modify Kconfig /
           Makefiles)
         - improve robustness of unaligned access handler and its interaction
           with window overflow/underflow exception handlers
         - deprecate atomic and spill registers syscalls
         - clean up Kconfig: remove orphan MATH_EMULATION, sort 'select'
           statements
         - wire up renameat2 syscall.
      
        Various fixes:
         - fix address checks in dma_{alloc,free}_coherent (runtime BUG)
         - fix access to THREAD_RA/THREAD_SP/THREAD_DS (debug build breakage)
         - fix TLBTEMP_BASE_2 region handling in fast_second_level_miss
           (runtime unrecoverable exception)
         - fix a6 and a7 handling in fast_syscall_xtensa (runtime userspace
           register clobbering)
         - fix kernel/user jump out of fast_unaligned (potential runtime
           unrecoverabl exception)
         - replace termios IOCTL code definitions with constants (userspace
           build breakage)"
      
      * tag 'xtensa-20140830' of git://github.com/czankel/xtensa-linux: (25 commits)
        xtensa: deprecate fast_xtensa and fast_spill_registers syscalls
        xtensa: don't allow overflow/underflow on unaligned stack
        xtensa: fix a6 and a7 handling in fast_syscall_xtensa
        xtensa: allow single-stepping through unaligned load/store
        xtensa: move invalid unaligned instruction handler closer to its users
        xtensa: make fast_unaligned store restartable
        xtensa: add double exception fixup handler for fast_unaligned
        xtensa: fix kernel/user jump out of fast_unaligned
        xtensa: configure kc705 for highmem
        xtensa: support highmem in aliasing cache flushing code
        xtensa: support aliasing cache in kmap
        xtensa: support aliasing cache in k[un]map_atomic
        xtensa: implement clear_user_highpage and copy_user_highpage
        xtensa: fix TLBTEMP_BASE_2 region handling in fast_second_level_miss
        xtensa: allow fixmap and kmap span more than one page table
        xtensa: make fixmap region addressing grow with index
        xtensa: fix access to THREAD_RA/THREAD_SP/THREAD_DS
        xtensa: add renameat2 syscall
        xtensa: fix address checks in dma_{alloc,free}_coherent
        xtensa: replace IOCTL code definitions with constants
        ...
      05bdb8c9
    • Guenter Roeck's avatar
      unicore32: Fix build error · ca98565a
      Guenter Roeck authored
      unicore32 builds fail with
      
        arch/unicore32/kernel/signal.c: In function ‘setup_frame’:
        arch/unicore32/kernel/signal.c:257: error: ‘usig’ undeclared (first use in this function)
        arch/unicore32/kernel/signal.c:279: error: ‘usig’ undeclared (first use in this function)
        arch/unicore32/kernel/signal.c: In function ‘handle_signal’:
        arch/unicore32/kernel/signal.c:306: warning: unused variable ‘tsk’
        arch/unicore32/kernel/signal.c: In function ‘do_signal’:
        arch/unicore32/kernel/signal.c:376: error: implicit declaration of function ‘get_signsl’
        make[1]: *** [arch/unicore32/kernel/signal.o] Error 1
        make: *** [arch/unicore32/kernel/signal.o] Error 2
      
      Bisect points to commit 649671c9 ("unicore32: Use get_signal()
      signal_setup_done()").
      
      This code never even compiled.  Reverting the patch does not work, since
      previously used functions no longer exist, so try to fix it up.  Compile
      tested only.
      
      Fixes: 649671c9 ("unicore32: Use get_signal() signal_setup_done()")
      Cc: Richard Weinberger <richard@nod.at>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ca98565a
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm · 94559a4a
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Various assorted fixes:
      
         - a couple of patches from Mark Rutland to resolve an errata with
           Cortex-A15 CPUs.
         - fix cpuidle for the CPU part ID changes in the last merge window
         - add support for a relocation which ARM binutils is generating in
           some circumstances"
      
      * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
        ARM: 8130/1: cpuidle/cpuidle-big_little: fix reading cpu id part number
        ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using dummy strex
        ARM: 8128/1: abort: don't clear the exclusive monitors
        ARM: 8127/1: module: add support for R_ARM_TARGET1 relocations
      94559a4a
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 19ed3eb9
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "Here's the weekly batch of fixes from arm-soc.
      
        The delta is a largeish negative delta, due to revert of SMP support
        for Broadcom's STB SoC -- it was accidentally merged before some
        issues had been addressed, so they will make a new attempt for 3.18.
        I didn't see a need for a full revert of the whole platform due to
        this, we're keeping the rest enabled.
      
        The rest is mostly:
      
         - a handful of DT fixes for i.MX (Hummingboard/Cubox-i in particular)
         - some MTD/NAND fixes for OMAP
         - minor DT fixes for shmobile
         - warning fix for UP builds on vexpress/spc
      
        There's also a couple of patches that wires up hwmod on TI's DRA7 SoC
        so it can boot.  Drivers and the rest had landed for 3.17, and it's
        small and isolated so it made sense to pick up now even if it's not a
        bugfix"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (23 commits)
        vexpress/spc: fix a build warning on array bounds
        ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
        ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() variants
        MAINTAINERS: catch special Rockchip code locations
        ARM: dts: microsom-ar8035: MDIO pad must be set open drain
        ARM: dts: omap54xx-clocks: Fix the l3 and l4 clock rates
        ARM: brcmstb: revert SMP support
        ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled
        ARM: dts: Enable UART wake-up events for beagleboard
        ARM: dts: Remove twl6030 clk32g "regulator"
        ARM: OMAP2+: omap_device: remove warning that clk alias already exists
        ARM: OMAP: fix %d confusingly prefixed with 0x in format string
        ARM: dts: DRA7: fix interrupt-cells for GPIO
        mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc()
        ARM: dts: omap3430-sdp: Revert to using software ECC for NAND
        ARM: OMAP2+: GPMC: Support Software ECC scheme via DT
        mtd: nand: omap: Revert to using software ECC by default
        ARM: dts: hummingboard/cubox-i: change SPDIF output to be more descriptive
        ARM: dts: hummingboard/cubox-i: add USB OC pinctrl configuration
        ARM: shmobile: r8a7791: add missing 0x0100 for SDCKCR
        ...
      19ed3eb9
  4. 31 Aug, 2014 7 commits
  5. 30 Aug, 2014 4 commits
    • Mark Brown's avatar
      Merge remote-tracking branches 'spi/fix/au1550', 'spi/fix/davinci',... · 360b2eae
      Mark Brown authored
      Merge remote-tracking branches 'spi/fix/au1550', 'spi/fix/davinci', 'spi/fix/doc', 'spi/fix/dw', 'spi/fix/omap-mcspi', 'spi/fix/pxa2xx', 'spi/fix/rockchip' and 'spi/fix/rspi' into spi-linus
      360b2eae
    • Mark Brown's avatar
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · fd5984d7
      Linus Torvalds authored
      Pull x86 fixes from Peter Anvin:
       "One patch to avoid assigning interrupts we don't actually have on
        non-PC platforms, and two patches that addresses bugs in the new
        IOAPIC assignment code"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, irq, PCI: Keep IRQ assignment for runtime power management
        x86: irq: Fix bug in setting IOAPIC pin attributes
        x86: Fix non-PC platform kernel crash on boot due to NULL dereference
      fd5984d7
    • Linus Torvalds's avatar
      Merge tag 'pm+acpi-3.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · ad6ede80
      Linus Torvalds authored
      Pull ACPI and power management fixes from Rafael Wysocki:
      
       - Fix for an ACPI regression related to the handling of fixed events
         that caused netlink routines to be (incorrectly) run in interrupt
         context from Lan Tianyu
      
       - Fix for an ACPI EC driver regression on Acer Aspire V5-573G that
         caused AC/battery plug/unplug and video brightness change
         notifications to be delayed on that machine from Lv Zheng
      
       - Fix for an ACPI device enumeration regression that caused ACPI driver
         probe to fail for some devices where it succeeded before (Rafael J
         Wysocki)
      
       - intel_pstate driver fix to prevent it from printing an information
         message for every CPU in the system on every boot from Andi Kleen
      
       - s5pv210 cpufreq driver fix to remove an __init annotation from a
         routine that in fact can be called at any time after init too from
         Mark Brown
      
       - New Intel Braswell device ID for the ACPI LPSS (Low-Power Subsystem)
         driver from Alan Cox
      
       - New Intel Braswell CPU ID for intel_pstate from Mika Westerberg
      
      * tag 'pm+acpi-3.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        cpufreq: s5pv210: Remove spurious __init annotation
        cpufreq: intel_pstate: Add CPU ID for Braswell processor
        intel_pstate: Turn per cpu printk into pr_debug
        ACPI / LPSS: Add ACPI IDs for Intel Braswell
        ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC
        ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set
        ACPI: Run fixed event device notifications in process context
        ACPI / scan: Allow ACPI drivers to bind to PNP device objects
      ad6ede80
  6. 29 Aug, 2014 9 commits