1. 25 May, 2014 10 commits
  2. 14 May, 2014 6 commits
  3. 12 May, 2014 8 commits
  4. 08 May, 2014 2 commits
  5. 05 May, 2014 1 commit
  6. 04 May, 2014 4 commits
  7. 03 May, 2014 9 commits
    • Catalin Marinas's avatar
      arm64: Mark the Applied Micro X-Gene SATA controller as DMA coherent · 7a8d1ec1
      Catalin Marinas authored
      Since the default DMA ops for arm64 are non-coherent, mark the X-Gene
      controller explicitly as dma-coherent to avoid additional cache
      maintenance.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: Loc Ho <lho@apm.com>
      7a8d1ec1
    • Catalin Marinas's avatar
      arm64: Use bus notifiers to set per-device coherent DMA ops · 6ecba8eb
      Catalin Marinas authored
      Recently, the default DMA ops have been changed to non-coherent for
      alignment with 32-bit ARM platforms (and DT files). This patch adds bus
      notifiers to be able to set the coherent DMA ops (with no cache
      maintenance) for devices explicitly marked as coherent via the
      "dma-coherent" DT property.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      6ecba8eb
    • Ritesh Harjani's avatar
      arm64: Make default dma_ops to be noncoherent · c7a4a765
      Ritesh Harjani authored
      Currently arm64 dma_ops is by default made coherent which makes it
      opposite in default policy from arm.
      
      Make default dma_ops to be noncoherent (same as arm), as currently there
      aren't any dma-capable drivers which assumes coherent ops
      Signed-off-by: default avatarRitesh Harjani <ritesh.harjani@gmail.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      c7a4a765
    • Marc Zyngier's avatar
      arm64: fixmap: fix missing sub-page offset for earlyprintk · f774b7d1
      Marc Zyngier authored
      Commit d57c33c5 (add generic fixmap.h) added (among other
      similar things) set_fixmap_io to deal with early ioremap of devices.
      
      More recently, commit bf4b558e (arm64: add early_ioremap support)
      converted the arm64 earlyprintk to use set_fixmap_io. A side effect of
      this conversion is that my virtual machines have stopped booting when
      I pass "earlyprintk=uart8250-8bit,0x3f8" to the guest kernel.
      
      Turns out that the new earlyprintk code doesn't care at all about
      sub-page offsets, and just assumes that the earlyprintk device will
      be page-aligned. Obviously, that doesn't play well with the above example.
      
      Further investigation shows that set_fixmap_io uses __set_fixmap instead
      of __set_fixmap_offset. A fix is to introduce a set_fixmap_offset_io that
      uses the latter, and to remove the superflous call to fix_to_virt
      (which only returns the value that set_fixmap_io has already given us).
      
      With this applied, my VMs are back in business. Tested on a Cortex-A57
      platform with kvmtool as platform emulation.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Acked-by: default avatarMark Salter <msalter@redhat.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      f774b7d1
    • Dave Anderson's avatar
      arm64: Fix for the arm64 kern_addr_valid() function · da6e4cb6
      Dave Anderson authored
      Fix for the arm64 kern_addr_valid() function to recognize
      virtual addresses in the kernel logical memory map.  The
      function fails as written because it does not check whether
      the addresses in that region are mapped at the pmd level to
      2MB or 512MB pages, continues the page table walk to the
      pte level, and issues a garbage value to pfn_valid().
      
      Tested on 4K-page and 64K-page kernels.
      Signed-off-by: default avatarDave Anderson <anderson@redhat.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      da6e4cb6
    • Linus Torvalds's avatar
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 0384dcae
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
       "This udpate delivers:
      
         - A fix for dynamic interrupt allocation on x86 which is required to
           exclude the GSI interrupts from the dynamic allocatable range.
      
           This was detected with the newfangled tablet SoCs which have GPIOs
           and therefor allocate a range of interrupts.  The MSI allocations
           already excluded the GSI range, so we never noticed before.
      
         - The last missing set_irq_affinity() repair, which was delayed due
           to testing issues
      
         - A few bug fixes for the armada SoC interrupt controller
      
         - A memory allocation fix for the TI crossbar interrupt controller
      
         - A trivial kernel-doc warning fix"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip: irq-crossbar: Not allocating enough memory
        irqchip: armanda: Sanitize set_irq_affinity()
        genirq: x86: Ensure that dynamic irq allocation does not conflict
        linux/interrupt.h: fix new kernel-doc warnings
        irqchip: armada-370-xp: Fix releasing of MSIs
        irqchip: armada-370-xp: implement the ->check_device() msi_chip operation
        irqchip: armada-370-xp: fix invalid cast of signed value into unsigned variable
      0384dcae
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 98facf0e
      Linus Torvalds authored
      Pull timer fixes from Thomas Gleixner:
       "This update brings along:
      
         - Two fixes for long standing bugs in the hrtimer code, one which
           prevents remote enqueuing and the other preventing arbitrary delays
           after a interrupt hang was detected
      
         - A fix in the timer wheel which prevents math overflow
      
         - A fix for a long standing issue with the architected ARM timer
           related to the C3STOP mechanism.
      
         - A trivial compile fix for nspire SoC clocksource"
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        timer: Prevent overflow in apply_slack
        hrtimer: Prevent remote enqueue of leftmost timers
        hrtimer: Prevent all reprogramming if hang detected
        clocksource: nspire: Fix compiler warning
        clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue
      98facf0e
    • Linus Torvalds's avatar
      Merge tag 'trace-fixes-v3.15-rc3' of... · 00622e61
      Linus Torvalds authored
      Merge tag 'trace-fixes-v3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
      
      Pull tracing fix from Steven Rostedt:
       "This is a small fix where the trigger code used the wrong
        rcu_dereference().  It required rcu_dereference_sched() instead of the
        normal rcu_dereference().  It produces a nasty RCU lockdep splat due
        to the incorrect rcu notation"
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      
      * tag 'trace-fixes-v3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Use rcu_dereference_sched() for trace event triggers
      00622e61
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Use rcu_dereference_sched() for trace event triggers · 561a4fe8
      Steven Rostedt (Red Hat) authored
      As trace event triggers are now part of the mainline kernel, I added
      my trace event trigger tests to my test suite I run on all my kernels.
      Now these tests get run under different config options, and one of
      those options is CONFIG_PROVE_RCU, which checks under lockdep that
      the rcu locking primitives are being used correctly. This triggered
      the following splat:
      
      ===============================
      [ INFO: suspicious RCU usage. ]
      3.15.0-rc2-test+ #11 Not tainted
      -------------------------------
      kernel/trace/trace_events_trigger.c:80 suspicious rcu_dereference_check() usage!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      4 locks held by swapper/1/0:
       #0:  ((&(&j_cdbs->work)->timer)){..-...}, at: [<ffffffff8104d2cc>] call_timer_fn+0x5/0x1be
       #1:  (&(&pool->lock)->rlock){-.-...}, at: [<ffffffff81059856>] __queue_work+0x140/0x283
       #2:  (&p->pi_lock){-.-.-.}, at: [<ffffffff8106e961>] try_to_wake_up+0x2e/0x1e8
       #3:  (&rq->lock){-.-.-.}, at: [<ffffffff8106ead3>] try_to_wake_up+0x1a0/0x1e8
      
      stack backtrace:
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15.0-rc2-test+ #11
      Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
       0000000000000001 ffff88007e083b98 ffffffff819f53a5 0000000000000006
       ffff88007b0942c0 ffff88007e083bc8 ffffffff81081307 ffff88007ad96d20
       0000000000000000 ffff88007af2d840 ffff88007b2e701c ffff88007e083c18
      Call Trace:
       <IRQ>  [<ffffffff819f53a5>] dump_stack+0x4f/0x7c
       [<ffffffff81081307>] lockdep_rcu_suspicious+0x107/0x110
       [<ffffffff810ee51c>] event_triggers_call+0x99/0x108
       [<ffffffff810e8174>] ftrace_event_buffer_commit+0x42/0xa4
       [<ffffffff8106aadc>] ftrace_raw_event_sched_wakeup_template+0x71/0x7c
       [<ffffffff8106bcbf>] ttwu_do_wakeup+0x7f/0xff
       [<ffffffff8106bd9b>] ttwu_do_activate.constprop.126+0x5c/0x61
       [<ffffffff8106eadf>] try_to_wake_up+0x1ac/0x1e8
       [<ffffffff8106eb77>] wake_up_process+0x36/0x3b
       [<ffffffff810575cc>] wake_up_worker+0x24/0x26
       [<ffffffff810578bc>] insert_work+0x5c/0x65
       [<ffffffff81059982>] __queue_work+0x26c/0x283
       [<ffffffff81059999>] ? __queue_work+0x283/0x283
       [<ffffffff810599b7>] delayed_work_timer_fn+0x1e/0x20
       [<ffffffff8104d3a6>] call_timer_fn+0xdf/0x1be^M
       [<ffffffff8104d2cc>] ? call_timer_fn+0x5/0x1be
       [<ffffffff81059999>] ? __queue_work+0x283/0x283
       [<ffffffff8104d823>] run_timer_softirq+0x1a4/0x22f^M
       [<ffffffff8104696d>] __do_softirq+0x17b/0x31b^M
       [<ffffffff81046d03>] irq_exit+0x42/0x97
       [<ffffffff81a08db6>] smp_apic_timer_interrupt+0x37/0x44
       [<ffffffff81a07a2f>] apic_timer_interrupt+0x6f/0x80
       <EOI>  [<ffffffff8100a5d8>] ? default_idle+0x21/0x32
       [<ffffffff8100a5d6>] ? default_idle+0x1f/0x32
       [<ffffffff8100ac10>] arch_cpu_idle+0xf/0x11
       [<ffffffff8107b3a4>] cpu_startup_entry+0x1a3/0x213
       [<ffffffff8102a23c>] start_secondary+0x212/0x219
      
      The cause is that the triggers are protected by rcu_read_lock_sched() but
      the data is dereferenced with rcu_dereference() which expects it to
      be protected with rcu_read_lock(). The proper reference should be
      rcu_dereference_sched().
      
      Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
      Cc: stable@vger.kernel.org # 3.14+
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      561a4fe8