1. 20 May, 2014 3 commits
    • Hans de Goede's avatar
      acer-wmi: Add Aspire 5741 to video_vendor_dmi_table · 9404cd95
      Hans de Goede authored
      The Aspire 5741 has broken acpi-video backlight control, so add it to the
      quirk table.
      
      References: https://bugzilla.redhat.com/show_bug.cgi?id=1012674Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarLee, Chun-Yi <jlee@suse.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9404cd95
    • Hans de Goede's avatar
      acer-wmi: Switch to acpi_video_unregister_backlight · d1337415
      Hans de Goede authored
      Switch from acpi_video_unregister(), to acpi_video_unregister_backlight(),
      so that the hotkeys handler registered by acpi-video stays in place.
      
      Since there are no mappings for the atkbd raw codes for the brightness
      keys used by newer Acer models in /lib/udev/hwdb.d/60-keyboard.hwdb, and
      since we map the wmi events with a code of KE_IGNORE, we rely on acpi-video
      to do the hotkey handling for us.
      
      For laptops such as the Acer Aspire 5750 which uses intel gfx this works
      despite us calling acpi_video_unregister() because the following happens:
      
       1) acpi-video module gets loaded (as it is a dependency of acer-wmi and i915)
       2) acpi-video does NOT call acpi_video_register()
       3) acer-wmi loads (assume it loads before i915), calls
          acpi_video_dmi_promote_vendor(); which sets
          ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
       4) calls acpi_video_unregister -> not registered, nop
       5) i915 loads, calls acpi_video_register
       6) acpi_video_register registers the acpi_notifier for the hotkeys,
          does NOT register a backlight device because of
          ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
      
      But on the Acer Aspire 5750G, which uses nvidia graphics the following happens:
       1) acpi-video module gets loaded (as it is a dependency of acer-wmi)
       2) acpi-video calls acpi_video_register()
       3) acpi_video_register registers the acpi_notifier for the hotkeys,
          and a backlight device
       4) acer-wmi loads, calls acpi_video_dmi_promote_vendor()
       5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier for
          the hotkeys AND the backlight device
      
      And we end up without any handler for the brightness hotkeys. This patch fixes
      this by switching over to acpi_video_unregister_backlight() which keeps the
      hotkey handler in place.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=35622Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d1337415
    • Hans de Goede's avatar
      ACPI / video: Add an acpi_video_unregister_backlight function · 1b7f37e1
      Hans de Goede authored
      Add an acpi_video_unregister_backlight function, which only unregisters
      the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
      driver need this as they don't want the acpi_video# backlight device, but do
      need the acpi-video driver for hotkey handling.
      
      Chances are that this new acpi_video_unregister_backlight() is actually
      what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor
      drivers which want to disable the acpi_video# backlight device, make 2 calls:
      
      acpi_video_dmi_promote_vendor();
      acpi_video_unregister();
      
      The intention here is to make things independent of when acpi_video_register()
      gets called. As acpi_video_register() will get called on acpi-video load time
      on non intel gfx machines, while it gets called on i915 load time on intel
      gfx machines.
      
      This leads to the following 2 interesting scenarios:
      
       a) intel gfx:
        1) acpi-video module gets loaded (as it is a dependency of acpi_vendor
           and i915)
        2) acpi-video does NOT call acpi_video_register()
        3) acpi_vendor loads (lets assume it loads before i915), calls
           acpi_video_dmi_promote_vendor(); which sets
           ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
        4) calls acpi_video_unregister -> not registered, nop
        5) i915 loads, calls acpi_video_register
        6) acpi_video_register registers the acpi_notifier for the hotkeys,
           does NOT register a backlight device because of
           ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
      
       b) non intel gfx
        1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
        2) acpi-video calls acpi_video_register()
        3) acpi_video_register registers the acpi_notifier for the hotkeys,
           and a backlight device
        4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
        5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier
           for the hotkeys AND the backlight device
      
      So here we have possibly the same acpi_vendor module, making the same calls,
      but with different results, in one cases acpi-video does handle hotkeys,
      in the other it does not.
      
      Note that the a) scenario turns into b) if we assume the i915 module loads
      before the vendor_acpi module, so we also have different behavior depending
      on module loading order!
      
      So as said I believe that quite a few existing acpi_vendor modules really
      always want the behavior of a), hence this patch adds a new
      acpi_video_unregister_backlight() which gives the behavior of a) independent
      of module loading order.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1b7f37e1
  2. 16 May, 2014 1 commit
  3. 06 May, 2014 2 commits
  4. 05 May, 2014 1 commit
  5. 04 May, 2014 4 commits
  6. 03 May, 2014 11 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
    • Linus Torvalds's avatar
      Merge tag 'pm+acpi-3.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 6c6ca9c2
      Linus Torvalds authored
      Pull ACPI and power management fixes from Rafael Wysocki:
       "A bunch of regression fixes this time.  They fix two regressions in
        the PNP subsystem, one in the ACPI processor driver and one in the
        ACPI EC driver, four cpufreq driver regressions and an unrelated bug
        in one of the drivers.  The regressions are recent or introduced in
        3.14.
      
        Specifics:
      
         - There are two bugs in the ACPI PNP core that cause errors to be
           returned if optional ACPI methods are not present.  After an ACPI
           core change made in 3.14 one of those errors leads to serial port
           suspend failures on some systems.  Fix from Rafael J Wysocki.
      
         - A recently added PNP quirk related to Intel chipsets intorduced a
           build error in unusual configurations (PNP without PCI).  Fix from
           Bjorn Helgaas.
      
         - An ACPI EC workaround related to system suspend on Samsung machines
           added in 3.14 introduced a race causing some valid EC events to be
           discarded.  Fix from Kieran Clancy.
      
         - The acpi-cpufreq driver fails to load on some systems after a 3.14
           commit related to APIC ID parsing that overlooked one corner case.
           Fix from Lan Tianyu.
      
         - Fix for a recently introduced build problem in the ppc-corenet
           cpufreq driver from Tim Gardner.
      
         - A recent cpufreq core change to ensure serialization of frequency
           transitions for drivers with a ->target_index() callback overlooked
           the fact that some of those drivers had been doing operations
           introduced by it into the core already by themselves.  That
           resulted in a mess in which the core and the drivers try to do the
           same thing and block each other which leads to deadlocks.  Fixes
           for the powernow-k7, powernow-k6, and longhaul cpufreq drivers from
           Srivatsa S Bhat.
      
         - Fix for a computational error in the powernow-k6 cpufreq driver
           from Srivatsa S Bhat"
      
      * tag 'pm+acpi-3.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        ACPI / processor: Fix failure of loading acpi-cpufreq driver
        PNP / ACPI: Do not return errors if _DIS or _SRS are not present
        PNP: Fix compile error in quirks.c
        ACPI / EC: Process rather than discard events in acpi_ec_clear
        cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost error
        cpufreq: powernow-k7: Fix double invocation of cpufreq_freq_transition_begin/end
        cpufreq: powernow-k6: Fix double invocation of cpufreq_freq_transition_begin/end
        cpufreq: powernow-k6: Fix incorrect comparison with max_multipler
        cpufreq: longhaul: Fix double invocation of cpufreq_freq_transition_begin/end
      6c6ca9c2
    • Linus Torvalds's avatar
      Merge tag 'dt-for-linus' of git://git.secretlab.ca/git/linux · e981e795
      Linus Torvalds authored
      Pull driver core deferred probe fix from Grant Likely:
       "Drivercore race condition fix (exposed by devicetree)
      
        This branch fixes a bug where a device can get stuck in the deferred
        list even though all its dependencies are met.  The bug has existed
        for a long time, but new platform conversions to device tree have
        exposed it.  This patch is needed to get those platforms working.
      
        This was the pending bug fix I mentioned in my previous pull request.
        Normally this would go through Greg's tree seeing that it is a
        drivercore change, but devicetree exposes the problem.  I've discussed
        with Greg and he okayed me asking you to pull directly"
      
      * tag 'dt-for-linus' of git://git.secretlab.ca/git/linux:
        drivercore: deferral race condition fix
      e981e795
  7. 02 May, 2014 8 commits
  8. 01 May, 2014 10 commits