1. 01 Jul, 2015 5 commits
    • Lv Zheng's avatar
      ACPICA: Tables: Enable default 64-bit FADT addresses favor · 0ea61381
      Lv Zheng authored
      ACPICA commit 4da56eeae0749dfe8491285c1e1fad48f6efafd8
      
      The following commit temporarily disables correct 64-bit FADT addresses
      favor during the period the root cause of the bug is not fixed:
       Commit: 85dbd580
       ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses.
      
      With enough protections, this patch re-enables 64-bit FADT addresses by
      default. If regressions are reported against such change, this patch should
      be bisected and reverted.
      Note that 64-bit FACS favor and 64-bit firmware waking vector favor are
      excluded by this commit in order not to break OSPMs. Lv Zheng.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
      Link: https://github.com/acpica/acpica/commit/4da56eea
      Cc: 3.15.1+ <stable@vger.kernel.org> # 3.15.1+
      Reported-and-tested-by: default avatarOswald Buddenhagen <ossi@kde.org>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0ea61381
    • Lv Zheng's avatar
      ACPICA: Tables: Fix an issue that FACS initialization is performed twice · c04be184
      Lv Zheng authored
      ACPICA commit 90f5332a15e9d9ba83831ca700b2b9f708274658
      
      This patch adds a new FACS initialization flag for acpi_tb_initialize().
      acpi_enable_subsystem() might be invoked several times in OS bootup process,
      and we don't want FACS initialization to be invoked twice. Lv Zheng.
      
      Link: https://github.com/acpica/acpica/commit/90f5332a
      Cc: All applicable <stable@vger.kernel.org> # All applicable
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c04be184
    • Lv Zheng's avatar
      ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS · f06147f9
      Lv Zheng authored
      ACPICA commit 368eb60778b27b6ae94d3658ddc902ca1342a963
      ACPICA commit 70f62a80d65515e1285fdeeb50d94ee6f07df4bd
      ACPICA commit a04dbfa308a48ab0b2d10519c54a6c533c5c8949
      ACPICA commit ebd544ed24c5a4faba11f265e228b7a821a729f5
      
      The following commit is reported to have broken s2ram on some platforms:
       Commit: 0249ed24
       ACPICA: Add option to favor 32-bit FADT addresses.
      The platform reports 2 FACS tables (which is not allowed by ACPI
      specification) and the new 32-bit address favor rule forces OSPMs to use
      the FACS table reported via FADT's X_FIRMWARE_CTRL field.
      
      The root cause of the reported bug might be one of the followings:
      1. BIOS may favor the 64-bit firmware waking vector address when the
         version of the FACS is greater than 0 and Linux currently only supports
         resuming from the real mode, so the 64-bit firmware waking vector has
         never been set and might be invalid to BIOS while the commit enables
         higher version FACS.
      2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the
         FADT while the commit doesn't set the firmware waking vector address of
         the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking
         vector address of the FACS reported by "X_FIRMWARE_CTRL".
      
      This patch excludes the cases that can trigger the bugs caused by the root
      cause 2.
      
      There is no handshaking mechanism can be used by OSPM to tell BIOS which
      FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still
      be used by BIOS and the 0 value of the 32-bit firmware waking vector might
      trigger such failure.
      
      This patch enables the firmware waking vectors for both 32bit/64bit FACS
      tables in order to ensure we can exclude the cases that trigger the bugs
      caused by the root cause 2. The exclusion is split into 2 commits so that
      if it turns out not to be necessary, this single commit can be reverted
      without affecting the useful one. Lv Zheng, Bob Moore.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
      Link: https://github.com/acpica/acpica/commit/368eb607
      Link: https://github.com/acpica/acpica/commit/70f62a80
      Link: https://github.com/acpica/acpica/commit/a04dbfa3
      Link: https://github.com/acpica/acpica/commit/ebd544edReported-and-tested-by: default avatarOswald Buddenhagen <ossi@kde.org>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f06147f9
    • Lv Zheng's avatar
      ACPICA: Tables: Enable both 32-bit and 64-bit FACS · c04e1fb4
      Lv Zheng authored
      ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486
      
      The following commit is reported to have broken s2ram on some platforms:
       Commit: 0249ed24
       ACPICA: Add option to favor 32-bit FADT addresses.
      The platform reports 2 FACS tables (which is not allowed by ACPI
      specification) and the new 32-bit address favor rule forces OSPMs to use
      the FACS table reported via FADT's X_FIRMWARE_CTRL field.
      
      The root cause of the reported bug might be one of the followings:
      1. BIOS may favor the 64-bit firmware waking vector address when the
         version of the FACS is greater than 0 and Linux currently only supports
         resuming from the real mode, so the 64-bit firmware waking vector has
         never been set and might be invalid to BIOS while the commit enables
         higher version FACS.
      2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the
         FADT while the commit doesn't set the firmware waking vector address of
         the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking
         vector address of the FACS reported by "X_FIRMWARE_CTRL".
      
      This patch excludes the cases that can trigger the bugs caused by the root
      cause 2.
      
      There is no handshaking mechanism can be used by OSPM to tell BIOS which
      FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still
      be used by BIOS and the 0 value of the 32-bit firmware waking vector might
      trigger such failure.
      
      This patch tries to favor 32bit FACS address in another way where both the
      FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL"
      are loaded so that further commit can set firmware waking vector in the
      both tables to ensure we can exclude the cases that trigger the bugs caused
      by the root cause 2. The exclusion is split into 2 commits as this commit
      is also useful for dumping more ACPI tables, it won't get reverted when
      such exclusion is no longer necessary. Lv Zheng.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
      Link: https://github.com/acpica/acpica/commit/f7b86f35
      Cc: 3.14.1+ <stable@vger.kernel.org> # 3.14.1+
      Reported-and-tested-by: default avatarOswald Buddenhagen <ossi@kde.org>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c04e1fb4
    • Lv Zheng's avatar
      ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS · aca2a5d3
      Lv Zheng authored
      ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4
      
      The following commit is reported to have broken s2ram on some platforms:
       Commit: 0249ed24
       ACPICA: Add option to favor 32-bit FADT addresses.
      The platform reports 2 FACS tables (which is not allowed by ACPI
      specification) and the new 32-bit address favor rule forces OSPMs to use
      the FACS table reported via FADT's X_FIRMWARE_CTRL field.
      
      The root cause of the reported bug might be one of the followings:
      1. BIOS may favor the 64-bit firmware waking vector address when the
         version of the FACS is greater than 0 and Linux currently only supports
         resuming from the real mode, so the 64-bit firmware waking vector has
         never been set and might be invalid to BIOS while the commit enables
         higher version FACS.
      2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the
         FADT while the commit doesn't set the firmware waking vector address of
         the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking
         vector address of the FACS reported by "X_FIRMWARE_CTRL".
      
      This patch excludes the cases that can trigger the bugs caused by the root
      cause 1.
      
      ACPI specification says:
      A. 32-bit FACS address (FIRMWARE_CTRL field in FADT):
         Physical memory address of the FACS, where OSPM and firmware exchange
         control information.
         If the X_FIRMWARE_CTRL field contains a non zero value then this field
         must be zero.
         A zero value indicates that no FACS is specified by this field.
      B. 64-bit FACS address (X_FIRMWARE_CTRL field in FADT):
         64bit physical memory address of the FACS.
         This field is used when the physical address of the FACS is above 4GB.
         If the FIRMWARE_CTRL field contains a non zero value then this field
         must be zero.
         A zero value indicates that no FACS is specified by this field.
      Thus the 32bit and 64bit firmware waking vector should indicate completely
      different resuming environment - real mode (1MB addressable) and non real
      mode (4GB+ addressable) and currently Linux only supports resuming from
      real mode.
      
      This patch enables 64-bit firmware waking vector for selected FACS via new
      acpi_set_firmware_waking_vectors() API so that it's up to OSPMs to
      determine which resuming mode should be used by BIOS and ACPICA changes
      won't trigger the bugs caused by the root cause 1. Lv Zheng.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
      Link: https://github.com/acpica/acpica/commit/7aa598d7Reported-and-tested-by: default avatarOswald Buddenhagen <ossi@kde.org>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      aca2a5d3
  2. 24 Jun, 2015 1 commit
  3. 23 Jun, 2015 1 commit
  4. 25 May, 2015 2 commits
  5. 22 May, 2015 19 commits
  6. 19 May, 2015 1 commit
  7. 12 May, 2015 1 commit
  8. 10 May, 2015 6 commits
    • Linus Torvalds's avatar
      Linux 4.1-rc3 · 030bbdbf
      Linus Torvalds authored
      030bbdbf
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 01d07351
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "I really need to get back to sending these on my Friday, instead of my
        Monday morning, but nothing too amazing in here: a few amdkfd fixes, a
        few radeon fixes, i915 fixes, one tegra fix and one core fix"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm: Zero out invalid vblank timestamp in drm_update_vblank_count.
        drm/tegra: Don't use vblank_disable_immediate on incapable driver.
        drm/radeon: stop trying to suspend UVD sessions
        drm/radeon: more strictly validate the UVD codec
        drm/radeon: make UVD handle checking more strict
        drm/radeon: make VCE handle check more strict
        drm/radeon: fix userptr lockup
        drm/radeon: fix userptr BO unpin bug v3
        drm/amdkfd: Initialize sdma vm when creating sdma queue
        drm/amdkfd: Don't report local memory size
        drm/amdkfd: allow unregister process with queues
        drm/i915: Drop PIPE-A quirk for 945GSE HP Mini
        drm/i915: Sink rate read should be saved in deca-kHz
        drm/i915/dp: there is no audio on port A
        drm/i915: Add missing MacBook Pro models with dual channel LVDS
        drm/i915: Assume dual channel LVDS if pixel clock necessitates it
        drm/radeon: don't setup audio on asics that don't support it
        drm/radeon: disable semaphores for UVD V1 (v2)
      01d07351
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2015-05-08' of git://anongit.freedesktop.org/drm-intel into drm-fixes · 332545b3
      Dave Airlie authored
      misc i915 fixes.
      
      * tag 'drm-intel-fixes-2015-05-08' of git://anongit.freedesktop.org/drm-intel:
        drm/i915: Drop PIPE-A quirk for 945GSE HP Mini
        drm/i915: Sink rate read should be saved in deca-kHz
        drm/i915/dp: there is no audio on port A
        drm/i915: Add missing MacBook Pro models with dual channel LVDS
        drm/i915: Assume dual channel LVDS if pixel clock necessitates it
      332545b3
    • Mario Kleiner's avatar
      drm: Zero out invalid vblank timestamp in drm_update_vblank_count. · fdb68e09
      Mario Kleiner authored
      Since commit 844b03f2 we make
      sure that after vblank irq off, we return the last valid
      (vblank count, vblank timestamp) pair to clients, e.g., during
      modesets, which is good.
      
      An overlooked side effect of that commit for kms drivers without
      support for precise vblank timestamping is that at vblank irq
      enable, when we update the vblank counter from the hw counter, we
      can't update the corresponding vblank timestamp, so now we have a
      totally mismatched timestamp for the new count to confuse clients.
      
      Restore old client visible behaviour from before Linux 3.17, but
      zero out the timestamp at vblank counter update (instead of disable
      as in original implementation) if we can't generate a meaningful
      timestamp immediately for the new vblank counter. This will fix
      this regression, so callers know they need to retry again later
      if they need a valid timestamp, but at the same time preserves
      the improvements made in the commit mentioned above.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: <stable@vger.kernel.org> #v3.17+
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      fdb68e09
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm · 41f2a93c
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "A set of ARM fixes:
      
         - fix an off-by-one error in the iommu DMA ops, which caused errors
           with a 4GiB size.
      
         - remove comments mentioning the non-existent CONFIG_CPU_ARM1020_CPU_IDLE
           macro.
      
         - remove useless CONFIG_CPU_ICACHE_STREAMING_DISABLE blocks, where
           this symbol never appeared in any Kconfig.
      
         - fix Feroceon code to cope with a previous change correctly (it
           incorrectly left an additional word in an assembly structure
           definition)
      
         - avoid a misleading IRQ affinity warning in the ARM PMU code for
           IRQs which are already affine to their CPUs.
      
         - fix the node name printed in the IRQ affinity warning"
      
      * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
        ARM: 8352/1: perf: Fix the pmu node name in warning message
        ARM: 8351/1: perf: don't warn about missing interrupt-affinity property for PPIs
        ARM: 8350/1: proc-feroceon: Fix feroceon_proc_info macro
        ARM: 8349/1: arch/arm/mm/proc-arm925.S: remove dead #ifdef block
        ARM: 8348/1: remove comments on CPU_ARM1020_CPU_IDLE
        ARM: 8347/1: dma-mapping: fix off-by-one check in arm_setup_iommu_dma_ops
      41f2a93c
    • Linus Torvalds's avatar
      Merge tag 'samsung-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung · 8425ac7a
      Linus Torvalds authored
      Pull samsung fixes from Kukjin Kim:
       "Here is Samsung fixes for v4.1.  Since I've missed to send this via
        arm-soc tree before v4.1-rc3, so I'm sending this to you directly
      
         - fix commit ea08de16 ("ARM: dts: Add DISP1 power domain for
           exynos5420") which causes 'unhandled fault: imprecise external
           abort' error when PD turned off.  ("make DP a consumer of DISP1
           power domain")
      
         - fix 's3c-rtc' probe failure on Odriod-X2/U2/U3 boards ("add
           'rtc_src' clock to rtc node for source clock of rtc")
      
         - fix typo for 'cpu-crit-0' trip point on exynos5420/5440
      
         - fix S2R failure on exynos5250-snow due to card power of Marvell
           WiFi driver (suspend/resume) ("add keep-power-in-susped to WiFi
           SDIO node")"
      
      * tag 'samsung-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
        ARM: dts: Add keep-power-in-suspend to WiFi SDIO node for exynos5250-snow
        ARM: dts: Fix typo in trip point temperature for exynos5420/5440
        ARM: dts: add 'rtc_src' clock to rtc node for exynos4412-odroid boards
        ARM: dts: Make DP a consumer of DISP1 power domain on Exynos5420
      8425ac7a
  9. 09 May, 2015 4 commits
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 8f59ae06
      Linus Torvalds authored
      Pull ARM SoC fixes from Arnd Bergmann:
       "A few patches have come up since the merge window.  The largest one is
        a rewrite of the PXA lubbock/mainstone IRQ handling.  This was already
        broken in 2011 by a change to the GPIO code and only noticed now.
      
        The other changes contained here are:
      
        MAINTAINERS file updates:
      
         - Ray Jui and Scott Branden are now co-maintainers for some of the
           mach-bcm chips, while Christian Daudt and Marc Carino have stepped
           down.
      
         - Andrew Victor is no longer maintaining at91.  Instead, Alexandre
           Belloni now becomes an official maintainer, after having done a
           bulk of the work for a while.
      
         - Baruch Siach, who added the mach-digicolor platform in 4.1 is now
           listed as maintainer
      
         - The git URL for mach-socfpga has changed
      
        Bug fixes:
      
         - Three bug fixes for new rockchip rk3288 code
      
         - A regression fix to make SD card support work on certain ux500
           boards
      
         - multiple smaller dts fixes for imx, omap, mvebu, and shmobile
      
         - a regression fiix for omap3 power consumption
      
         - a fix for regression in the ARM CCI bus driver
      
        Configuration changes:
      
         - more imx platforms are now enabled in multi_v7_defconfig"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (39 commits)
        MAINTAINERS: add Conexant Digicolor machines entry
        MAINTAINERS: socfpga: update the git repo for SoCFPGA
        ARM: multi_v7_defconfig: Select more FSL SoCs
        MAINTAINERS: replace an AT91 maintainer
        drivers: CCI: fix used_mask init in validate_group()
        bus: omap_l3_noc: Fix master id address decoding for OMAP5
        bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instance
        ARM: dts: dra7: Fix efuse register size for ABB
        ARM: dts: am57xx-beagle-x15: Switch GPIO fan number
        ARM: dts: am57xx-beagle-x15: Switch UART mux pins
        ARM: dts: am437x-sk: reduce col-scan-delay-us
        ARM: dts: am437x-sk: fix for new newhaven display module revision
        ARM: dts: am57xx-beagle-x15: Fix RTC aliases
        ARM: dts: am57xx-beagle-x15: Fix IRQ type for mcp7941x
        ARM: dts: omap3: Add #iommu-cells to isp and iva iommu
        ARM: omap2plus_defconfig: Enable EXTCON_USB_GPIO
        ARM: dts: OMAP3-N900: Add microphone bias voltages
        ARM: OMAP2+: Fix omap off idle power consumption creeping up
        MAINTAINERS: Update brcmstb entry
        MAINTAINERS: Remove Christian Daudt for mach-bcm
        ...
      8f59ae06
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace · 51dfcb07
      Linus Torvalds authored
      Pull user-namespace fix from Eric Biederman:
       "Eric Windish recently reported a really bug that allows mounting fresh
        copies of proc and sysfs when it really should not be allowed.  The
        code attempted to verify that proc and sysfs were fully visible but
        there is a test missing to ensure that the root of the filesystem is
        visible.  Doh!
      
        The following patch fixes that.
      
        This fixes a containment issue that the docker folks are seeing"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
        mnt: Fix fs_fully_visible to verify the root directory is visible
      51dfcb07
    • Linus Torvalds's avatar
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 9d88f22a
      Linus Torvalds authored
      Pull irq updates from Thomas Gleixner:
       "Two patches from the irq departement:
      
         - a simple fix to make dummy_irq_chip usable for wakeup scenarios
      
         - removal of the gic arch_extn hackery.  Now that all users are
           converted we really want to get rid of the interface so people wont
           come up with new use cases"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip: gic: Drop support for gic_arch_extn
        genirq: Set IRQCHIP_SKIP_SET_WAKE flag for dummy_irq_chip
      9d88f22a
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 95f3b1f4
      Linus Torvalds authored
      Pull timer fix from Thomas Gleixner:
       "A simple fix to actually shut down a detached device instead of
        keeping it active"
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        clockevents: Shutdown detached clockevent device
      95f3b1f4