1. 09 May, 2016 18 commits
    • Imre Deak's avatar
      drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume · 973ef0b6
      Imre Deak authored
      commit 5eaa60c7 upstream.
      
      The driver's VDD on/off logic assumes that whenever the VDD is on we
      also hold an AUX power domain reference. Since BIOS can leave the VDD on
      during booting and resuming and on DDI platforms we won't take a
      corresponding power reference, the above assumption won't hold on those
      platforms and an eventual delayed VDD off work will do an extraneous AUX
      power domain put resulting in a refcount underflow. Fix this the same
      way we did this for non-DDI DP encoders:
      
      commit 6d93c0c4 ("drm/i915: fix VDD state tracking after system
      resume")
      
      At the same time call the DP encoder suspend handler the same way as the
      non-DDI DP encoders do to flush any pending VDD off work. Leaving the
      work running may cause a HW access where we don't expect this (at a point
      where power domains are suspended already).
      
      While at it remove an unnecessary function call indirection.
      
      This fixed for me AUX refcount underflow problems on BXT during
      suspend/resume.
      
      CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com
      (cherry picked from commit bf93ba67)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      973ef0b6
    • Imre Deak's avatar
      drm/i915: Fix system resume if PCI device remained enabled · 6199c5e9
      Imre Deak authored
      commit dab9a266 upstream.
      
      During system resume we depended on pci_enable_device() also putting the
      device into PCI D0 state. This won't work if the PCI device was already
      enabled but still in D3 state. This is because pci_enable_device() is
      refcounted and will not change the HW state if called with a non-zero
      refcount. Leaving the device in D3 will make all subsequent device
      accesses fail.
      
      This didn't cause a problem most of the time, since we resumed with an
      enable refcount of 0. But it fails at least after module reload because
      after that we also happen to leak a PCI device enable reference: During
      probing we call drm_get_pci_dev() which will enable the PCI device, but
      during device removal drm_put_dev() won't disable it. This is a bug of
      its own in DRM core, but without much harm as it only leaves the PCI
      device enabled. Fixing it is also a bit more involved, due to DRM
      mid-layering and because it affects non-i915 drivers too. The fix in
      this patch is valid regardless of the problem in DRM core.
      
      v2:
      - Add a code comment about the relation of this fix to the freeze/thaw
        vs. the suspend/resume phases. (Ville)
      - Add a code comment about the inconsistent ordering of set power state
        and device enable calls. (Chris)
      
      CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460979954-14503-1-git-send-email-imre.deak@intel.com
      (cherry picked from commit 44410cd0)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      [ kamal: backport to 4.2-stable ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      6199c5e9
    • Michael Neuling's avatar
      cxl: Keep IRQ mappings on context teardown · 857461a9
      Michael Neuling authored
      commit d6776bba upstream.
      
      Keep IRQ mappings on context teardown.  This won't leak IRQs as if we
      allocate the mapping again, the generic code will give the same
      mapping used last time.
      
      Doing this works around a race in the generic code. Masking the
      interrupt introduces a race which can crash the kernel or result in
      IRQ that is never EOIed. The lost of EOI results in all subsequent
      mappings to the same HW IRQ never receiving an interrupt.
      
      We've seen this race with cxl test cases which are doing heavy context
      startup and teardown at the same time as heavy interrupt load.
      
      A fix to the generic code is being investigated also.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Tested-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Acked-by: default avatarIan Munsie <imunsie@au1.ibm.com>
      Tested-by: default avatarVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      857461a9
    • Gustavo Padovan's avatar
      drm/virtio: send vblank event after crtc updates · 900f5de6
      Gustavo Padovan authored
      commit 9a11d2e7 upstream.
      
      virtio_gpu was failing to send vblank events when using the atomic IOCTL
      with the DRM_MODE_PAGE_FLIP_EVENT flag set. This patch fixes each and
      enables atomic pageflips updates.
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      [ kamal: backport to 4.2-stable: older crtc api ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      900f5de6
    • cpaul@redhat.com's avatar
      drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1() · 134f51cd
      cpaul@redhat.com authored
      commit 263efde3 upstream.
      
      We can thank KASAN for finding this, otherwise I probably would have spent
      hours on it. This fixes a somewhat harder to trigger kernel panic, occuring
      while enabling MST where the port we were currently updating the payload on
      would have all of it's refs dropped before we finished what we were doing:
      
      ==================================================================
      BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018
      Read of size 4 by task Xorg/973
      =============================================================================
      BUG kmalloc-2048 (Tainted: G    B   W      ): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175
      	___slab_alloc+0x472/0x490
      	__slab_alloc+0x20/0x40
      	kmem_cache_alloc_trace+0x151/0x190
      	drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper]
      	drm_dp_send_link_address+0x526/0x960 [drm_kms_helper]
      	drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper]
      	drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper]
      	process_one_work+0x562/0x1350
      	worker_thread+0xd9/0x1390
      	kthread+0x1c5/0x260
      	ret_from_fork+0x22/0x40
      INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175
      	__slab_free+0x17f/0x2d0
      	kfree+0x169/0x180
      	drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper]
      	drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper]
      	process_one_work+0x562/0x1350
      	worker_thread+0xd9/0x1390
      	kthread+0x1c5/0x260
      	ret_from_fork+0x22/0x40
      
      which on this T460s, would eventually lead to kernel panics in somewhat
      random places later in intel_mst_enable_dp() if we got lucky enough.
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      134f51cd
    • Roman Pen's avatar
      workqueue: fix ghost PENDING flag while doing MQ IO · ce75b13e
      Roman Pen authored
      commit 346c09f8 upstream.
      
      The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
      with the following backtrace:
      
      [  601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds.
      [  601.347574]       Tainted: G           O    4.4.5-1-storage+ #6
      [  601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  601.348142] kworker/u129:5  D ffff880803077988     0  1636      2 0x00000000
      [  601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server]
      [  601.348999]  ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000
      [  601.349662]  ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0
      [  601.350333]  ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38
      [  601.350965] Call Trace:
      [  601.351203]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
      [  601.351444]  [<ffffffff815b01d5>] schedule+0x35/0x80
      [  601.351709]  [<ffffffff815b2dd2>] schedule_timeout+0x192/0x230
      [  601.351958]  [<ffffffff812d43f7>] ? blk_flush_plug_list+0xc7/0x220
      [  601.352208]  [<ffffffff810bd737>] ? ktime_get+0x37/0xa0
      [  601.352446]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
      [  601.352688]  [<ffffffff815af784>] io_schedule_timeout+0xa4/0x110
      [  601.352951]  [<ffffffff815b3a4e>] ? _raw_spin_unlock_irqrestore+0xe/0x10
      [  601.353196]  [<ffffffff815b093b>] bit_wait_io+0x1b/0x70
      [  601.353440]  [<ffffffff815b056d>] __wait_on_bit+0x5d/0x90
      [  601.353689]  [<ffffffff81127bd0>] wait_on_page_bit+0xc0/0xd0
      [  601.353958]  [<ffffffff81096db0>] ? autoremove_wake_function+0x40/0x40
      [  601.354200]  [<ffffffff81127cc4>] __filemap_fdatawait_range+0xe4/0x140
      [  601.354441]  [<ffffffff81127d34>] filemap_fdatawait_range+0x14/0x30
      [  601.354688]  [<ffffffff81129a9f>] filemap_write_and_wait_range+0x3f/0x70
      [  601.354932]  [<ffffffff811ced3b>] blkdev_fsync+0x1b/0x50
      [  601.355193]  [<ffffffff811c82d9>] vfs_fsync_range+0x49/0xa0
      [  601.355432]  [<ffffffff811cf45a>] blkdev_write_iter+0xca/0x100
      [  601.355679]  [<ffffffff81197b1a>] __vfs_write+0xaa/0xe0
      [  601.355925]  [<ffffffff81198379>] vfs_write+0xa9/0x1a0
      [  601.356164]  [<ffffffff811c59d8>] kernel_write+0x38/0x50
      
      The underlying device is a null_blk, with default parameters:
      
        queue_mode    = MQ
        submit_queues = 1
      
      Verification that nullb0 has something inflight:
      
      root@pserver8:~# cat /sys/block/nullb0/inflight
             0        1
      root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \;
      ...
      /sys/block/nullb0/mq/0/cpu2/rq_list
      CTX pending:
              ffff8838038e2400
      ...
      
      During debug it became clear that stalled request is always inserted in
      the rq_list from the following path:
      
         save_stack_trace_tsk + 34
         blk_mq_insert_requests + 231
         blk_mq_flush_plug_list + 281
         blk_flush_plug_list + 199
         wait_on_page_bit + 192
         __filemap_fdatawait_range + 228
         filemap_fdatawait_range + 20
         filemap_write_and_wait_range + 63
         blkdev_fsync + 27
         vfs_fsync_range + 73
         blkdev_write_iter + 202
         __vfs_write + 170
         vfs_write + 169
         kernel_write + 56
      
      So blk_flush_plug_list() was called with from_schedule == true.
      
      If from_schedule is true, that means that finally blk_mq_insert_requests()
      offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue,
      i.e. it calls kblockd_schedule_delayed_work_on().
      
      That means, that we race with another CPU, which is about to execute
      __blk_mq_run_hw_queue() work.
      
      Further debugging shows the following traces from different CPUs:
      
        CPU#0                                  CPU#1
        ----------------------------------     -------------------------------
        reqeust A inserted
        STORE hctx->ctx_map[0] bit marked
        kblockd_schedule...() returns 1
        <schedule to kblockd workqueue>
                                               request B inserted
                                               STORE hctx->ctx_map[1] bit marked
                                               kblockd_schedule...() returns 0
        *** WORK PENDING bit is cleared ***
        flush_busy_ctxs() is executed, but
        bit 1, set by CPU#1, is not observed
      
      As a result request B pended forever.
      
      This behaviour can be explained by speculative LOAD of hctx->ctx_map on
      CPU#0, which is reordered with clear of PENDING bit and executed _before_
      actual STORE of bit 1 on CPU#1.
      
      The proper fix is an explicit full barrier <mfence>, which guarantees
      that clear of PENDING bit is to be executed before all possible
      speculative LOADS or STORES inside actual work function.
      Signed-off-by: default avatarRoman Pen <roman.penyaev@profitbricks.com>
      Cc: Gioh Kim <gi-oh.kim@profitbricks.com>
      Cc: Michael Wang <yun.wang@profitbricks.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: linux-block@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ce75b13e
    • Conrad Kostecki's avatar
      ALSA: hda - Add dock support for ThinkPad X260 · 79b636f7
      Conrad Kostecki authored
      commit 037e1197 upstream.
      
      Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013
      docking station series (basic, pro, ultra).
      Signed-off-by: default avatarConrad Kostecki <ck+linuxkernel@bl4ckb0x.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      79b636f7
    • Hans Verkuil's avatar
      [media] v4l2-dv-timings.h: fix polarity for 4k formats · 56db89fa
      Hans Verkuil authored
      commit 3020ca71 upstream.
      
      The VSync polarity was negative instead of positive for the 4k CEA formats.
      I probably copy-and-pasted these from the DMT 4k format, which does have a
      negative VSync polarity.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Reported-by: default avatarMartin Bugge <marbugge@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      56db89fa
    • Jasem Mutlaq's avatar
      USB: serial: cp210x: add Straizona Focusers device ids · c0feac89
      Jasem Mutlaq authored
      commit 613ac23a upstream.
      
      Adding VID:PID for Straizona Focusers to cp210x driver.
      Signed-off-by: default avatarJasem Mutlaq <mutlaqja@ikarustech.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c0feac89
    • Mike Manning's avatar
      USB: serial: cp210x: add ID for Link ECU · ed62a6f8
      Mike Manning authored
      commit 1d377f4d upstream.
      
      The Link ECU is an aftermarket ECU computer for vehicles that provides
      full tuning abilities as well as datalogging and displaying capabilities
      via the USB to Serial adapter built into the device.
      Signed-off-by: default avatarMike Manning <michael@bsch.com.au>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ed62a6f8
    • Laszlo Ersek's avatar
      efi: Fix out-of-bounds read in variable_matches() · a0b95d34
      Laszlo Ersek authored
      commit 630ba0cc upstream.
      
      The variable_matches() function can currently read "var_name[len]", for
      example when:
      
       - var_name[0] == 'a',
       - len == 1
       - match_name points to the NUL-terminated string "ab".
      
      This function is supposed to accept "var_name" inputs that are not
      NUL-terminated (hence the "len" parameter"). Document the function, and
      access "var_name[*match]" only if "*match" is smaller than "len".
      Reported-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Matthew Garrett <mjg59@coreos.com>
      Cc: Jason Andryuk <jandryuk@gmail.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Link: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a0b95d34
    • Javier Martinez Canillas's avatar
      i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared · 364d78d4
      Javier Martinez Canillas authored
      commit 10ff4c52 upstream.
      
      The exynos5 I2C controller driver always prepares and enables a clock
      before using it and then disables unprepares it when the clock is not
      used anymore.
      
      But this can cause a possible ABBA deadlock in some scenarios since a
      driver that uses regmap to access its I2C registers, will first grab
      the regmap lock and then the I2C xfer function will grab the prepare
      lock when preparing the I2C clock. But since the clock driver also
      uses regmap for I2C accesses, preparing a clock will first grab the
      prepare lock and then the regmap lock when using the regmap API.
      
      An example of this happens on the Exynos5422 Odroid XU4 board where a
      s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
      share the same I2C regmap.
      
      The possible deadlock is reported by the kernel lockdep:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(sec_core:428:(regmap)->lock);
                                      lock(prepare_lock);
                                      lock(sec_core:428:(regmap)->lock);
         lock(prepare_lock);
      
        *** DEADLOCK ***
      
      Fix it by leaving the code prepared on probe and use {en,dis}able in
      the I2C transfer function.
      
      This patch is similar to commit 34e81ad5 ("i2c: s3c2410: fix ABBA
      deadlock by keeping clock prepared") that fixes the same bug in other
      driver for an I2C controller found in Samsung SoCs.
      Reported-by: default avatarAnand Moon <linux.amoon@gmail.com>
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Reviewed-by: default avatarAnand Moon <linux.amoon@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      364d78d4
    • Michael Ellerman's avatar
      i2c: cpm: Fix build break due to incompatible pointer types · 376c18ac
      Michael Ellerman authored
      commit 609d5a1b upstream.
      
      Since commit ea8daa7b ("kbuild: Add option to turn incompatible
      pointer check into error"), assignments from an incompatible pointer
      types have become a hard error, eg:
      
        drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of
        'dma_alloc_coherent' from incompatible pointer type
      
      Fix the build break by converting txdma & rxdma to dma_addr_t.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Fixes: ea8daa7bSigned-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      376c18ac
    • Richard Leitner's avatar
      iio: ak8975: fix maybe-uninitialized warning · 2ec66bab
      Richard Leitner authored
      commit 05be8d41 upstream.
      
      If i2c_device_id *id is NULL and acpi_match_device returns NULL too,
      then chipset may be unitialized when accessing &ak_def_array[chipset] in
      ak8975_probe. Therefore initialize chipset to AK_MAX_TYPE, which will
      return an error when not changed.
      
      This patch fixes the following maybe-uninitialized warning:
      
      drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’:
      drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used
      uninitialized in this function [-Wmaybe-uninitialized]
        data->def = &ak_def_array[chipset];
      Signed-off-by: default avatarRichard Leitner <dev@g0hl1n.net>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2ec66bab
    • Krzysztof Kozlowski's avatar
      iio: ak8975: Fix NULL pointer exception on early interrupt · 7f209cc1
      Krzysztof Kozlowski authored
      commit 07d2390e upstream.
      
      In certain probe conditions the interrupt came right after registering
      the handler causing a NULL pointer exception because of uninitialized
      waitqueue:
      
      $ udevadm trigger
      i2c-gpio i2c-gpio-1: using pins 143 (SDA) and 144 (SCL)
      i2c-gpio i2c-gpio-3: using pins 53 (SDA) and 52 (SCL)
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = e8b38000
      [00000000] *pgd=00000000
      Internal error: Oops: 5 [#1] SMP ARM
      Modules linked in: snd_soc_i2s(+) i2c_gpio(+) snd_soc_idma snd_soc_s3c_dma snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore ac97_bus spi_s3c64xx pwm_samsung dwc2 exynos_adc phy_exynos_usb2 exynosdrm exynos_rng rng_core rtc_s3c
      CPU: 0 PID: 717 Comm: data-provider-m Not tainted 4.6.0-rc1-next-20160401-00011-g1b8d87473b9e-dirty #101
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      (...)
      (__wake_up_common) from [<c0379624>] (__wake_up+0x38/0x4c)
      (__wake_up) from [<c0a41d30>] (ak8975_irq_handler+0x28/0x30)
      (ak8975_irq_handler) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140)
      (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68)
      (handle_irq_event) from [<c0389c40>] (handle_edge_irq+0xf0/0x19c)
      (handle_edge_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34)
      (generic_handle_irq) from [<c05ee360>] (exynos_eint_gpio_irq+0x50/0x68)
      (exynos_eint_gpio_irq) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140)
      (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68)
      (handle_irq_event) from [<c0389a70>] (handle_fasteoi_irq+0xb4/0x194)
      (handle_fasteoi_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34)
      (generic_handle_irq) from [<c03860b4>] (__handle_domain_irq+0x5c/0xb4)
      (__handle_domain_irq) from [<c0301774>] (gic_handle_irq+0x54/0x94)
      (gic_handle_irq) from [<c030c910>] (__irq_usr+0x50/0x80)
      
      The bug was reproduced on exynos4412-trats2 (with a max77693 device also
      using i2c-gpio) after building max77693 as a module.
      
      Fixes: 94a6d5cf ("iio:ak8975 Implement data ready interrupt handling")
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Tested-by: default avatarGregor Boirie <gregor.boirie@parrot.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7f209cc1
    • Oleksij Rempel's avatar
      ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation · 9b2dfb26
      Oleksij Rempel authored
      commit de478a61 upstream.
      
      by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
      mask_m & mask_p initialisation. This coused a performance regression
      on ar9281.
      
      Fixes: f911085f ("ath9k: split ar5008_hw_spur_mitigate and reuse common code in ar9002_hw_spur_mitigate.")
      Reported-by: default avatarGustav Frederiksen <lkml2017@openmailbox.org>
      Tested-by: default avatarGustav Frederiksen <lkml2017@openmailbox.org>
      Signed-off-by: default avatarOleksij Rempel <linux@rempel-privat.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9b2dfb26
    • Mark Brown's avatar
      ASoC: dapm: Make sure we have a card when displaying component widgets · e58e8daa
      Mark Brown authored
      commit 47325078 upstream.
      
      The dummy component is reused for all cards so we special case and don't
      bind it to any of them.  This means that code like that displaying the
      component widgets that tries to look at the card will crash.  In the
      future we will fix this by ensuring that the dummy component looks like
      other components but that is invasive and so not suitable for a fix.
      Instead add a special case check here.
      Reported-by: default avatarHarry Pan <harry.pan@intel.com>
      Suggested-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      [ kamal: backport to 4.2-stable ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e58e8daa
    • Sugar Zhang's avatar
      ASoC: rt5640: Correct the digital interface data select · 1c4cd5c5
      Sugar Zhang authored
      commit 653aa464 upstream.
      
      this patch corrects the interface adc/dac control register definition
      according to datasheet.
      Signed-off-by: default avatarSugar Zhang <sugar.zhang@rock-chips.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1c4cd5c5
  2. 02 May, 2016 2 commits
    • Ignat Korchagin's avatar
      USB: usbip: fix potential out-of-bounds write · 7679a59d
      Ignat Korchagin authored
      commit b348d7dd upstream.
      
      Fix potential out-of-bounds write to urb->transfer_buffer
      usbip handles network communication directly in the kernel. When receiving a
      packet from its peer, usbip code parses headers according to protocol. As
      part of this parsing urb->actual_length is filled. Since the input for
      urb->actual_length comes from the network, it should be treated as untrusted.
      Any entity controlling the network may put any value in the input and the
      preallocated urb->transfer_buffer may not be large enough to hold the data.
      Thus, the malicious entity is able to write arbitrary data to kernel memory.
      Signed-off-by: default avatarIgnat Korchagin <ignat.korchagin@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reference: CVE-2016-3955
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7679a59d
    • Hector Marco-Gisbert's avatar
      x86/mm/32: Enable full randomization on i386 and X86_32 · 861d04db
      Hector Marco-Gisbert authored
      commit 8b8addf8 upstream.
      
      Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only
      the stack and the executable are randomized but not other mmapped files
      (libraries, vDSO, etc.). This patch enables randomization for the
      libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode.
      
      By default on i386 there are 8 bits for the randomization of the libraries,
      vDSO and mmaps which only uses 1MB of VA.
      
      This patch preserves the original randomness, using 1MB of VA out of 3GB or
      4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR.
      
      The first obvious security benefit is that all objects are randomized (not
      only the stack and the executable) in legacy mode which highly increases
      the ASLR effectiveness, otherwise the attackers may use these
      non-randomized areas. But also sensitive setuid/setgid applications are
      more secure because currently, attackers can disable the randomization of
      these applications by setting the ulimit stack to "unlimited". This is a
      very old and widely known trick to disable the ASLR in i386 which has been
      allowed for too long.
      
      Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE
      personality flag, but fortunately this doesn't work on setuid/setgid
      applications because there is security checks which clear Security-relevant
      flags.
      
      This patch always randomizes the mmap_legacy_base address, removing the
      possibility to disable the ASLR by setting the stack to "unlimited".
      Signed-off-by: default avatarHector Marco-Gisbert <hecmargi@upv.es>
      Acked-by: default avatarIsmael Ripoll Ripoll <iripoll@upv.es>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: akpm@linux-foundation.org
      Cc: kees Cook <keescook@chromium.org>
      Link: http://lkml.kernel.org/r/1457639460-5242-1-git-send-email-hecmargi@upv.esSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Reference: CVE-2016-3672
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      861d04db
  3. 29 Apr, 2016 1 commit
  4. 26 Apr, 2016 19 commits