Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on May 23, 2015
  1. @zeroepoch

    md/raid0: fix restore to sector variable in raid0_make_request

    zeroepoch authored committed
    The variable "sector" in "raid0_make_request()" was improperly updated
    by a call to "sector_div()" which modifies its first argument in place.
    Commit 47d6897 restored this variable
    after the call for later re-use.  Unfortunetly the restore was done after
    the referenced variable "bio" was advanced.  This lead to the original
    value and the restored value being different.  Here we move this line to
    the proper place.
    
    One observed side effect of this bug was discarding a file though
    unlinking would cause an unrelated file's contents to be discarded.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Fixes: 47d6897 ("md/raid0: fix bug with chunksize not a power of 2.")
    Cc: stable@vger.kernel.org (any that received above backport)
    URL: https://bugzilla.kernel.org/show_bug.cgi?id=98501
Commits on May 18, 2015
  1. fix merge conflict

    authored
  2. Merge pull request #3 from Hubbitus/pf-4.0

    authored
    ck-4.0: fix BFS compilation with -Werror=strict-prototypes
  3. @Hubbitus

    Fix bfs compilation with -Werror=strict-prototypes

    Hubbitus authored
    static inline void grq_priodl_lock()
     does not take arguments, so should be declared as:
    static inline void grq_priodl_lock(void)
    
    With -Werror=strict-prototypes (default in Fedora I believe) it lead to fail build:
    kernel/sched/bfs.c:522:20: error: function declaration isn't a prototype [-Werror=strict-prototypes]
     static inline void grq_priodl_lock()
    
    Full log: https://kojipkgs.fedoraproject.org//work/tasks/258/9750258/build.log
Commits on May 17, 2015
  1. @gregkh

    Linux 4.0.4

    gregkh authored
  2. @zetalog @gregkh

    ACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx h…

    zetalog authored gregkh committed
    …elpers.
    
    commit 1d0a0b2 upstream.
    
    ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6
    
    For physical addresses, since the address may exceed 32-bit address range
    after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT
    and ACPI_FORMAT_UINT64() instead of
    ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT().
    
    This patch also removes above replaced macros as there are no users.
    
    This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
    kernel builds.
    
    Link: acpica/acpica@b606123
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
    Signed-off-by: George G. Davis <george_davis@mentor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. @zetalog @gregkh

    ACPICA: Utilities: Cleanup to convert physical address printing formats.

    zetalog authored gregkh committed
    commit cc2080b upstream.
    
    ACPICA commit 7f06739db43a85083a70371c14141008f20b2198
    
    For physical addresses, since the address may exceed 32-bit address range
    after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to
    convert the %p formats.
    
    This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
    kernel builds.
    
    Link: acpica/acpica@7f06739
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
    Signed-off-by: George G. Davis <george_davis@mentor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. @zetalog @gregkh

    ACPICA: Utilities: Cleanup to enforce ACPI_PHYSADDR_TO_PTR()/ACPI_PTR…

    zetalog authored gregkh committed
    …_TO_PHYSADDR().
    
    commit 6d3fd3c upstream.
    
    ACPICA commit 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf
    
    There are code pieces converting pointers using "(acpi_physical_address) x"
    or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them.
    
    Known issues:
    1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field
       For the conversions around the table fields, it is better to fix it with
       alignment also fixed. So this patch doesn't modify such code. There
       should be no functional problem by leaving them unchanged.
    
    Link: acpica/acpica@154f6d0
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
    Signed-off-by: George G. Davis <george_davis@mentor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. @zetalog @gregkh

    ACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_…

    zetalog authored gregkh committed
    …address.
    
    commit f254e3c upstream.
    
    ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3
    
    OSPMs like Linux expect an acpi_physical_address returning value from
    acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't
    equal to sizeof (acpi_physical_address):
      drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default]
      In file included from include/acpi/acpi.h:64:0,
                       from include/linux/acpi.h:36,
                       from drivers/acpi/osl.c:41:
      include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *'
    This patch corrects acpi_find_root_pointer().
    
    Link: acpica/acpica@7d9fd64
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
    Signed-off-by: George G. Davis <george_davis@mentor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. @gregkh

    coredump: accept any write method

    Al Viro authored gregkh committed
    commit 86cc058 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. @khoroshilov @gregkh

    sound/oss: fix deadlock in sequencer_ioctl(SNDCTL_SEQ_OUTOFBAND)

    khoroshilov authored gregkh committed
    commit bc26d4d upstream.
    
    A deadlock can be initiated by userspace via ioctl(SNDCTL_SEQ_OUTOFBAND)
    on /dev/sequencer with TMR_ECHO midi event.
    
    In this case the control flow is:
    sound_ioctl()
    -> case SND_DEV_SEQ:
       case SND_DEV_SEQ2:
         sequencer_ioctl()
         -> case SNDCTL_SEQ_OUTOFBAND:
              spin_lock_irqsave(&lock,flags);
              play_event();
              -> case EV_TIMING:
                   seq_timing_event()
                   -> case TMR_ECHO:
                        seq_copy_to_input()
                        -> spin_lock_irqsave(&lock,flags);
    
    It seems that spin_lock_irqsave() around play_event() is not necessary,
    because the only other call location in seq_startplay() makes the call
    without acquiring spinlock.
    
    So, the patch just removes spinlocks around play_event().
    By the way, it removes unreachable code in seq_timing_event(),
    since (seq_mode == SEQ_2) case is handled in the beginning.
    
    Compile tested only.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. @gregkh

    ARM: 8307/1: psci: move psci firmware calls out of line

    Mark Rutland authored gregkh committed
    commit c097877 upstream.
    
    arm64 builds with GCC 5 have caused the __asmeq assertions in the PSCI
    calling code to fire, so move the ARM PSCI calls out of line into their
    own assembly file for consistency and to safeguard against the same
    issue occuring with the 32-bit toolchain.
    
    [will: brought into line with arm64 implementation]
    
    Reported-by: Andy Whitcroft <apw@canonical.com>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Kevin Hilman <khilman@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. @gregkh

    mmc: sh_mmcif: Fix timeout value for command request

    Takeshi Kihara authored gregkh committed
    commit bad4371 upstream.
    
    f9fd54f ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout")
    changed the timeout value from 1000 jiffies to 1s. In the case where
    HZ is 1000 the values are the same. However, for smaller HZ values the
    timeout is now smaller, 1s instead of 10s in the case of HZ=100.
    
    Since the timeout occurs in spite of a normal data transfer a timeout of
    10s seems more appropriate. This restores the previous timeout in the
    case where HZ=100 and results in an increase over the previous timeout
    for larger values of HZ.
    
    Fixes: f9fd54f ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout")
    Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
    [horms: rewrote changelog to refer to HZ]
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. @grygoriyS @gregkh

    mmc: core: add missing pm event in mmc_pm_notify to fix hib restore

    grygoriyS authored gregkh committed
    commit 184af16 upstream.
    
    The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
    as result mmc_rescan() could be scheduled and executed at
    late hibernation restore stages when MMC device is suspended
    already - which, in turn, will lead to system crash on TI dra7-evm board:
    
    WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
    44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access
    
    Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().
    
    Fixes: 4c2ef25 (mmc: fix all hangs related to mmc/sd card...)
    Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. @gregkh

    mmc: card: Don't access RPMB partitions for normal read/write

    Chuanxiao Dong authored gregkh committed
    commit 4e93b9a upstream.
    
    During kernel boot, it will try to read some logical sectors
    of each block device node for the possible partition table.
    
    But since RPMB partition is special and can not be accessed
    by normal eMMC read / write CMDs, it will cause below error
    messages during kernel boot:
    ...
     mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
     mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00
     mmcblk0rpmb: retrying using single block read
     mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
     mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
     mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
     mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
     mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
     mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
     end_request: I/O error, dev mmcblk0rpmb, sector 0
     Buffer I/O error on device mmcblk0rpmb, logical block 0
     end_request: I/O error, dev mmcblk0rpmb, sector 8
     Buffer I/O error on device mmcblk0rpmb, logical block 1
     end_request: I/O error, dev mmcblk0rpmb, sector 16
     Buffer I/O error on device mmcblk0rpmb, logical block 2
     end_request: I/O error, dev mmcblk0rpmb, sector 24
     Buffer I/O error on device mmcblk0rpmb, logical block 3
    ...
    
    This patch will discard the access request in eMMC queue if
    it is RPMB partition access request. By this way, it avoids
    trigger above error messages.
    
    Fixes: 090d25f ("mmc: core: Expose access to RPMB partition")
    Signed-off-by: Yunpeng Gao <yunpeng.gao@intel.com>
    Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
    Tested-by: Michael Shigorin <mike@altlinux.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. @gregkh

    pinctrl: Don't just pretend to protect pinctrl_maps, do it for real

    Doug Anderson authored gregkh committed
    commit c5272a2 upstream.
    
    Way back, when the world was a simpler place and there was no war, no
    evil, and no kernel bugs, there was just a single pinctrl lock.  That
    was how the world was when (57291ce pinctrl: core device tree mapping
    table parsing support) was written.  In that case, there were
    instances where the pinctrl mutex was already held when
    pinctrl_register_map() was called, hence a "locked" parameter was
    passed to the function to indicate that the mutex was already locked
    (so we shouldn't lock it again).
    
    A few years ago in (42fed7b pinctrl: move subsystem mutex to
    pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex.
    ...but (oops) we forgot to re-think about the whole "locked" parameter
    for pinctrl_register_map().  Basically the "locked" parameter appears
    to still refer to whether the bigger pinctrl_dev mutex is locked, but
    we're using it to skip locks of our (now separate) pinctrl_maps_mutex.
    
    That's kind of a bad thing(TM).  Probably nobody noticed because most
    of the calls to pinctrl_register_map happen at boot time and we've got
    synchronous device probing.  ...and even cases where we're
    asynchronous don't end up actually hitting the race too often.  ...but
    after banging my head against the wall for a bug that reproduced 1 out
    of 1000 reboots and lots of looking through kgdb, I finally noticed
    this.
    
    Anyway, we can now safely remove the "locked" parameter and go back to
    a war-free, evil-free, and kernel-bug-free world.
    
    Fixes: 42fed7b ("pinctrl: move subsystem mutex to pinctrl_dev struct")
    Signed-off-by: Doug Anderson <dianders@chromium.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. @gregkh

    drm/radeon: more strictly validate the UVD codec

    Christian König authored gregkh committed
    commit d52cdfa upstream.
    
    MPEG 2/4 are only supported since UVD3.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. @gregkh

    drm/radeon: make UVD handle checking more strict

    Christian König authored gregkh committed
    commit a1b403d upstream.
    
    Invalid messages can crash the hw otherwise.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. @gregkh

    drm/radeon: make VCE handle check more strict

    Christian König authored gregkh committed
    commit 29c63fe upstream.
    
    Invalid handles can crash the hw.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. @gregkh

    drm/radeon: fix userptr BO unpin bug v3

    monk.liu authored gregkh committed
    commit db12973 upstream.
    
    Fixing a memory leak with userptrs.
    
    v2: clean up the loop, use an iterator instead
    v3: remove unused variable
    
    Signed-off-by: monk.liu <monk.liu@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. @gregkh

    drm/radeon: don't setup audio on asics that don't support it

    Alex Deucher authored gregkh committed
    commit d73a824 upstream.
    
    bug: https://bugzilla.kernel.org/show_bug.cgi?id=97701
    
    Reported-by: Mikael Pettersson <mikpelinux@gmail.com>
    Tested-by: Mikael Pettersson <mikpelinux@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. @gregkh

    drm/radeon: disable semaphores for UVD V1 (v2)

    Christian König authored gregkh committed
    commit 013ead4 upstream.
    
    Hardware doesn't seem to work correctly, just block userspace in this case.
    
    v2: add missing defines
    
    Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  19. @gregkh

    drm/amdkfd: Initialize sdma vm when creating sdma queue

    Xihan Zhang authored gregkh committed
    commit 79b066b upstream.
    
    This patch fixes a bug where sdma vm wasn't initialized when
    an sdma queue was created in HWS mode.
    
    This caused GPUVM faults to appear on dmesg and it is one of the
    causes that SDMA queues are not working.
    
    Signed-off-by: Xihan Zhang <xihan.zhang@amd.com>
    Reviewed-by: Ben Goz <ben.goz@amd.comt>
    Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  20. @gabbayo @gregkh

    drm/amdkfd: allow unregister process with queues

    gabbayo authored gregkh committed
    commit 1e5ec95 upstream.
    
    Sometimes we might unregister process that have queues, because we couldn't
    preempt the queues. Until now we blocked it with BUG_ON but instead just
    print it as debug.
    
    Reviewed-by: Ben Goz <ben.goz@amd.com>
    Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  21. @jnikula @gregkh

    drm/i915/dp: there is no audio on port A

    jnikula authored gregkh committed
    commit 9fcb170 upstream.
    
    The eDP port A register on PCH split platforms has a slightly different
    register layout from the other ports, with bit 6 being either alternate
    scrambler reset or reserved, depending on the generation. Our
    misinterpretation of the bit as audio has lead to warning.
    
    Fix this by not enabling audio on port A, since none of our platforms
    support audio on port A anyway.
    
    v2: DDI doesn't have audio on port A either (Sivakumar Thulasimani)
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89958
    Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
    Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  22. @gregkh

    drm/i915: Add missing MacBook Pro models with dual channel LVDS

    Lukas Wunner authored gregkh committed
    commit 3916e3f upstream.
    
    Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models
    shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz)
    as a BTO option, both versions used dual channel LVDS even though
    the smaller one would have fit into a single channel.
    
    Notes:
      Bug report showing that the MacBookPro8,2 with 1440x900 uses dual
      channel LVDS (this lead to it being hardcoded in intel_lvds.c by
      Daniel Vetter with commit 618563e):
        https://bugzilla.kernel.org/show_bug.cgi?id=42842
    
      If i915.lvds_channel_mode=2 is missing even though the machine needs
      it, every other vertical line is white and consequently, only the left
      half of the screen is visible (verified by myself on a MacBookPro9,1).
    
      Forum posting concerning a MacBookPro6,2 with 1440x900, author is
      using i915.lvds_channel_mode=2 on the kernel command line, proving
      that the machine uses dual channels:
        https://bbs.archlinux.org/viewtopic.php?id=185770
    
      Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all
      MacBook Pro "A1286" models, and that model number encompasses the
      MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's
      driven with dual channel LVDS:
        http://www.ebay.com/itm/-/400690878560
        http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286
        http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf
    
      Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones
      with i915 graphics and dual channel LVDS, so that list should be
      complete. And the 8,2 is already in intel_lvds.c.
    
      Possible motivation to use dual channel LVDS even on the 1440x900
      models: Reduce the number of different parts, i.e. use identical logic
      boards and display cabling on both versions and the only differing
      component is the panel.
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Acked-by: Jani Nikula <jani.nikula@intel.com>
    [Jani: included notes in the commit message for posterity]
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  23. @gregkh

    drm/i915: Assume dual channel LVDS if pixel clock necessitates it

    Lukas Wunner authored gregkh committed
    commit 6f317cf upstream.
    
    Single channel LVDS maxes out at 112 MHz, anything above must be dual
    channel. This avoids the need to specify i915.lvds_channel_mode=2 on
    all 17" MacBook Pro models with i915 graphics since they had 1920x1200
    (193 MHz), plus those 15" pre-retina models which had a resolution
    of 1680x1050 (119 MHz) as a BTO option.
    
    Source for 112 MHz limit of single channel LVDS is section 2.3 of:
    https://01.org/linuxgraphics/sites/default/files/documentation/ivb_ihd_os_vol3_part4.pdf
    
    v2: Avoid hardcoding 17" models by assuming dual channel LVDS if the
    resolution necessitates it, suggested by Jani Nikula.
    
    v3: Fix typo, thanks Joonas Lahtinen.
    
    v4: Split commit in two, suggested by Ville Syrjälä.
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Tested-by: Lukas Wunner <lukas@wunner.de>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    [Jani: included spec reference into the commit message]
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  24. @kleinerm @gregkh

    drm: Zero out invalid vblank timestamp in drm_update_vblank_count.

    kleinerm authored gregkh committed
    commit fdb68e0 upstream.
    
    Since commit 844b03f 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: Mario Kleiner <mario.kleiner.de@gmail.com>
    Cc: <stable@vger.kernel.org> #v3.17+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
  25. @storulf @gregkh

    ARM: ux500: Enable GPIO regulator for SD-card for snowball

    storulf authored gregkh committed
    commit 11133db upstream.
    
    Fixes: c94a4ab ("ARM: ux500: Disable the MMCI gpio-regulator by default")
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  26. @storulf @gregkh

    ARM: ux500: Enable GPIO regulator for SD-card for HREF boards

    storulf authored gregkh committed
    commit f9a8c39 upstream.
    
    Fixes: c94a4ab ("ARM: ux500: Disable the MMCI gpio-regulator by default")
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  27. @storulf @gregkh

    ARM: ux500: Move GPIO regulator for SD-card into board DTSs

    storulf authored gregkh committed
    commit 53d2669 upstream.
    
    The GPIO regulator for the SD-card isn't a ux500 SOC configuration, but
    instead it's specific to the board. Move the definition of it, into the
    board DTSs.
    
    Fixes: c94a4ab ("ARM: ux500: Disable the MMCI gpio-regulator by default")
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  28. @gregkh

    ARM: net fix emit_udiv() for BPF_ALU | BPF_DIV | BPF_K intruction.

    Nicolas Schichan authored gregkh committed
    commit 19fc99d upstream.
    
    In that case, emit_udiv() will be called with rn == ARM_R0 (r_scratch)
    and loading rm first into ARM_R0 will result in jit_udiv() function
    being called the same dividend and divisor. Fix that by loading rn
    first into ARM_R1 and then rm into ARM_R0.
    
    Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
    Fixes: aee636c (bpf: do not use reciprocal divide)
    Acked-by: Mircea Gherzan <mgherzan@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  29. @tmlind @gregkh

    ARM: OMAP2+: Fix omap off idle power consumption creeping up

    tmlind authored gregkh committed
    commit 102bcb6 upstream.
    
    If we use a combination of VMODE and I2C4 for retention modes,
    eventually the off idle power consumption will creep up by about
    23mW, even during off mode with I2C4 always staying enabled.
    
    Turns out this is because of erratum i531 "Extra Power Consumed
    When Repeated Start Operation Mode Is Enabled on I2C Interface
    Dedicated for Smart Reflex (I2C4)" as pointed out by Nishanth
    Menon <nm@ti.com>.
    
    Let's fix the issue by adding i2c_cfg_clear_mask for the bits
    to clear when initializing the I2C4 adapter so we can clear
    SREN bit that drives the I2C4 lines low otherwise when there
    is no traffic.
    
    Fixes: 3b8c4eb ("ARM: OMAP3: Fix idle mode signaling for
    sys_clkreq and sys_off_mode")
    Cc: Kevin Hilman <khilman@kernel.org>
    Cc: Tero Kristo <t-kristo@ti.com>
    Reviewed-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  30. @gclement @gregkh

    ARM: mvebu: armada-xp-openblocks-ax3-4: Disable internal RTC

    gclement authored gregkh committed
    commit 750e30d upstream.
    
    There is no crystal connected to the internal RTC on the Open Block
    AX3. So let's disable it in order to prevent the kernel probing the
    driver uselessly. Eventually this patches removes the following
    warning message from the boot log:
    "rtc-mv d0010300.rtc: internal RTC not ticking"
    
    Acked-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Something went wrong with that request. Please try again.