1. 11 11月, 2016 7 次提交
  2. 09 11月, 2016 5 次提交
    • L
      drm/imx: disable planes before DC · 5ced937b
      Lucas Stach 提交于
      If the DC clock is disabled before the attached IDMACs are properly
      stopped the IDMACs may hang the IPU or even the whole system.
      
      Make sure the IDMACs are in safe state by disabling the planes before
      removal of the DC clock.
      
      Also set the atomic parameter to false to stop calling the atomic_begin
      hook, which does nothing useful as we immediately afterwards turn off
      vblank interrupts and possibly send the pending vblank event.
      
      Fixes: 33f14235 (drm/imx: atomic phase 1: Use transitional atomic
                           CRTC and plane helpers)
      Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      5ced937b
    • S
      drm/fsl-dcu: disable planes before disabling CRTC · 3d6f3710
      Stefan Agner 提交于
      After disabling and reenabling the CRTC the DCU sometimes got stuck
      displaying the whole screen with a solid color. Disabling and
      reenabling the CRTC did not recover from the situation. This was
      often reproducable by just restarting the X-Server.
      
      The disabling sequence is not explicitly documented. But it turns
      out that disabling the planes before disabling the CRTC seems to
      prevent the above situation from happening.
      
      Use the callback ->atomic_disable instead of ->disable which allows
      to use the drm_atomic_helper_disable_planes_on_crtc() helper to
      disable planes before disabling the controller.
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      3d6f3710
    • S
      drm/fsl-dcu: update all registers on flush · 93daeeca
      Stefan Agner 提交于
      Use the UPDATE_MODE READREG bit to initiate a register transfer
      on flush. This makes sure that we flush all registers only once
      for all planes.
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      93daeeca
    • S
      drm/fsl-dcu: do not update when modifying irq registers · 34a515d2
      Stefan Agner 提交于
      The IRQ status and mask registers are not "double buffered" according
      to the reference manual. Hence, there is no extra transfer/update
      write needed when modifying these registers.
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      34a515d2
    • A
      drm/amd/powerplay: return false instead of -EINVAL · f20024d8
      Andrew Shadura 提交于
      Returning -EINVAL from a bool-returning function
      phm_check_smc_update_required_for_display_configuration has an unexpected
      effect of returning true, which is probably not what was intended.
      Replace -EINVAL by false.
      
      The only place this function is called from is
      psm_adjust_power_state_dynamic in
      drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106:
      
      	if (!equal || phm_check_smc_update_required_for_display_configuration(hwmgr)) {
      		phm_apply_state_adjust_rules(hwmgr, requested, pcurrent);
      		phm_set_power_state(hwmgr, &pcurrent->hardware, &requested->hardware);
      		hwmgr->current_ps = requested;
      	}
      
      It seems to expect a boolean value here.
      
      This issue has been found using the following Coccinelle semantic patch
      written by Peter Senna Tschudin:
      <smpl>
      @@
      identifier f;
      constant C;
      typedef bool;
      @@
      bool f (...){
      <+...
      * return -C;
      ...+>
      }
      </smpl>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NAndrew Shadura <andrew.shadura@collabora.co.uk>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      f20024d8
  3. 08 11月, 2016 8 次提交
  4. 05 11月, 2016 2 次提交
    • N
      PCI: designware: Check for iATU unroll support after initializing host · 416379f9
      Niklas Cassel 提交于
      dw_pcie_iatu_unroll_enabled() reads a dbi_base register.  Reading any
      dbi_base register before pp->ops->host_init has been called causes
      "imprecise external abort" on platforms like ARTPEC-6, where the PCIe
      module is disabled at boot and first enabled in pp->ops->host_init.  Move
      dw_pcie_iatu_unroll_enabled() to dw_pcie_setup_rc(), since it is after
      pp->ops->host_init, but before pp->iatu_unroll_enabled is actually used.
      
      Fixes: a0601a47 ("PCI: designware: Add iATU Unroll feature")
      Tested-by: NJames Le Cuirot <chewi@gentoo.org>
      Signed-off-by: NNiklas Cassel <niklas.cassel@axis.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NJoao Pinto <jpinto@synopsys.com>
      Acked-by: NOlof Johansson <olof@lixom.net>
      416379f9
    • V
      i2c: core: fix NULL pointer dereference under race condition · 147b36d5
      Vladimir Zapolskiy 提交于
      Race condition between registering an I2C device driver and
      deregistering an I2C adapter device which is assumed to manage that
      I2C device may lead to a NULL pointer dereference due to the
      uninitialized list head of driver clients.
      
      The root cause of the issue is that the I2C bus may know about the
      registered device driver and thus it is matched by bus_for_each_drv(),
      but the list of clients is not initialized and commonly it is NULL,
      because I2C device drivers define struct i2c_driver as static and
      clients field is expected to be initialized by I2C core:
      
        i2c_register_driver()             i2c_del_adapter()
          driver_register()                 ...
            bus_add_driver()                ...
              ...                           bus_for_each_drv(..., __process_removed_adapter)
            ...                               i2c_do_del_adapter()
          ...                                   list_for_each_entry_safe(..., &driver->clients, ...)
          INIT_LIST_HEAD(&driver->clients);
      
      To solve the problem it is sufficient to do clients list head
      initialization before calling driver_register().
      
      The problem was found while using an I2C device driver with a sluggish
      registration routine on a bus provided by a physically detachable I2C
      master controller, but practically the oops may be reproduced under
      the race between arbitraty I2C device driver registration and managing
      I2C bus device removal e.g. by unbinding the latter over sysfs:
      
      % echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
        Unable to handle kernel NULL pointer dereference at virtual address 00000000
        Internal error: Oops: 17 [#1] SMP ARM
        CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
        Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
        task: e5ada400 task.stack: e4936000
        PC is at i2c_do_del_adapter+0x20/0xcc
        LR is at __process_removed_adapter+0x14/0x1c
        Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
        Control: 10c5387d  Table: 35bd004a  DAC: 00000051
        Process sh (pid: 533, stack limit = 0xe4936210)
        Stack: (0xe4937d28 to 0xe4938000)
        Backtrace:
        [<c0667be0>] (i2c_do_del_adapter) from [<c0667cc0>] (__process_removed_adapter+0x14/0x1c)
        [<c0667cac>] (__process_removed_adapter) from [<c0516998>] (bus_for_each_drv+0x6c/0xa0)
        [<c051692c>] (bus_for_each_drv) from [<c06685ec>] (i2c_del_adapter+0xbc/0x284)
        [<c0668530>] (i2c_del_adapter) from [<bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx])
        [<bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<c051a838>] (platform_drv_remove+0x2c/0x44)
        [<c051a80c>] (platform_drv_remove) from [<c05183d8>] (__device_release_driver+0x90/0x12c)
        [<c0518348>] (__device_release_driver) from [<c051849c>] (device_release_driver+0x28/0x34)
        [<c0518474>] (device_release_driver) from [<c0517150>] (unbind_store+0x80/0x104)
        [<c05170d0>] (unbind_store) from [<c0516520>] (drv_attr_store+0x28/0x34)
        [<c05164f8>] (drv_attr_store) from [<c0298acc>] (sysfs_kf_write+0x50/0x54)
        [<c0298a7c>] (sysfs_kf_write) from [<c029801c>] (kernfs_fop_write+0x100/0x214)
        [<c0297f1c>] (kernfs_fop_write) from [<c0220130>] (__vfs_write+0x34/0x120)
        [<c02200fc>] (__vfs_write) from [<c0221088>] (vfs_write+0xa8/0x170)
        [<c0220fe0>] (vfs_write) from [<c0221e74>] (SyS_write+0x4c/0xa8)
        [<c0221e28>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)
      Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      147b36d5
  5. 04 11月, 2016 1 次提交
  6. 03 11月, 2016 3 次提交
    • S
      firewire: net: fix fragmented datagram_size off-by-one · e9300a4b
      Stefan Richter 提交于
      RFC 2734 defines the datagram_size field in fragment encapsulation
      headers thus:
      
          datagram_size:  The encoded size of the entire IP datagram.  The
          value of datagram_size [...] SHALL be one less than the value of
          Total Length in the datagram's IP header (see STD 5, RFC 791).
      
      Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
      this field with a -/+1 offset:
      
          ether1394_tx() /* transmit */
              ether1394_encapsulate_prep()
                  hdr->ff.dg_size = dg_size - 1;
      
          ether1394_data_handler() /* receive */
              if (hdr->common.lf == ETH1394_HDR_LF_FF)
                  dg_size = hdr->ff.dg_size + 1;
              else
                  dg_size = hdr->sf.dg_size + 1;
      
      Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
      byte sized datagrams in fragments with datagram_size=1499 if link
      fragmentation is required.
      
      Only firewire-net sets and gets datagram_size without this offset.  The
      result is lacking interoperability of firewire-net with OS X, Windows
      XP, and presumably Linux' eth1394.  (I did not test with the latter.)
      For example, FTP data transfers to a Linux firewire-net box with max_rec
      smaller than the 1500 bytes MTU
        - from OS X fail entirely,
        - from Win XP start out with a bunch of fragmented datagrams which
          time out, then continue with unfragmented datagrams because Win XP
          temporarily reduces the MTU to 576 bytes.
      
      So let's fix firewire-net's datagram_size accessors.
      
      Note that firewire-net thereby loses interoperability with unpatched
      firewire-net, but only if link fragmentation is employed.  (This happens
      with large broadcast datagrams, and with large datagrams on several
      FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
      and it can be worked around by setting a small enough MTU.)
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      e9300a4b
    • S
      firewire: net: guard against rx buffer overflows · 667121ac
      Stefan Richter 提交于
      The IP-over-1394 driver firewire-net lacked input validation when
      handling incoming fragmented datagrams.  A maliciously formed fragment
      with a respectively large datagram_offset would cause a memcpy past the
      datagram buffer.
      
      So, drop any packets carrying a fragment with offset + length larger
      than datagram_size.
      
      In addition, ensure that
        - GASP header, unfragmented encapsulation header, or fragment
          encapsulation header actually exists before we access it,
        - the encapsulated datagram or fragment is of nonzero size.
      Reported-by: NEyal Itkin <eyal.itkin@gmail.com>
      Reviewed-by: NEyal Itkin <eyal.itkin@gmail.com>
      Fixes: CVE 2016-8633
      Cc: stable@vger.kernel.org
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      667121ac
    • G
      virtio-gpu: fix vblank events · eed6f0ed
      Gerd Hoffmann 提交于
      virtio-gpu sends vblank events in virtio_gpu_crtc_atomic_flush, and
      because of that it must be called for disabled planes too.  Ask
      drm_atomic_helper_commit_planes to do that.
      
      v2: update to use new drm_atomic_helper_commit_planes() API.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      eed6f0ed
  7. 02 11月, 2016 6 次提交
  8. 01 11月, 2016 8 次提交