1. 06 5月, 2014 20 次提交
  2. 30 3月, 2014 3 次提交
    • D
      Input: mousedev - fix race when creating mixed device · e4dbedc7
      Dmitry Torokhov 提交于
      We should not be using static variable mousedev_mix in methods that can be
      called before that singleton gets assigned. While at it let's add open and
      close methods to mousedev structure so that we do not need to test if we
      are dealing with multiplexor or normal device and simply call appropriate
      method directly.
      
      This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=71551Reported-by: NGiulioDP <depasquale.giulio@gmail.com>
      Tested-by: NGiulioDP <depasquale.giulio@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      e4dbedc7
    • E
      Input: don't modify the id of ioctl-provided ff effect on upload failure · fc7392aa
      Elias Vanderstuyft 提交于
      If a new (id == -1) ff effect was uploaded from userspace,
      ff-core.c::input_ff_upload() will have assigned a positive number to the
      new effect id.  Currently, evdev.c::evdev_do_ioctl() will save this new id
      to userspace, regardless of whether the upload succeeded or not.
      
      On upload failure, this can be confusing because the dev->ff->effects[]
      array will not contain an element at the index of that new effect id.
      
      This patch fixes this by leaving the id unchanged after upload fails.
      
      Note: Unfortunately applications should still expect changed effect id for
      quite some time.
      
      This has been discussed on:
      http://www.mail-archive.com/linux-input@vger.kernel.org/msg08513.html
      ("ff-core effect id handling in case of a failed effect upload")
      Suggested-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NElias Vanderstuyft <elias.vds@gmail.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      fc7392aa
    • A
      rbd: drop an unsafe assertion · 638c323c
      Alex Elder 提交于
      Olivier Bonvalet reported having repeated crashes due to a failed
      assertion he was hitting in rbd_img_obj_callback():
      
          Assertion failure in rbd_img_obj_callback() at line 2165:
      	rbd_assert(which >= img_request->next_completion);
      
      With a lot of help from Olivier with reproducing the problem
      we were able to determine the object and image requests had
      already been completed (and often freed) at the point the
      assertion failed.
      
      There was a great deal of discussion on the ceph-devel mailing list
      about this.  The problem only arose when there were two (or more)
      object requests in an image request, and the problem was always
      seen when the second request was being completed.
      
      The problem is due to a race in the window between setting the
      "done" flag on an object request and checking the image request's
      next completion value.  When the first object request completes, it
      checks to see if its successor request is marked "done", and if
      so, that request is also completed.  In the process, the image
      request's next_completion value is updated to reflect that both
      the first and second requests are completed.  By the time the
      second request is able to check the next_completion value, it
      has been set to a value *greater* than its own "which" value,
      which caused an assertion to fail.
      
      Fix this problem by skipping over any completion processing
      unless the completing object request is the next one expected.
      Test only for inequality (not >=), and eliminate the bad
      assertion.
      Tested-by: NOlivier Bonvalet <ob@daevel.fr>
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Reviewed-by: NSage Weil <sage@inktank.com>
      Reviewed-by: NIlya Dryomov <ilya.dryomov@inktank.com>
      638c323c
  3. 29 3月, 2014 7 次提交
  4. 28 3月, 2014 5 次提交
  5. 27 3月, 2014 5 次提交
    • D
      drm/nouveau: fail runtime pm properly. · adbbdbac
      Dave Airlie 提交于
      If we were on a non-optimus device, we'd return -EINVAL, this would
      lead to the over engineered runtime pm system to go into an error
      state, subsequent get_sync's would fail, so we'd never be able
      to open the device again.
      
      (like really get_sync shouldn't fail if the device isn't powered
      down).
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      adbbdbac
    • D
      drm/udl: take reference to device struct for dma-bufs · 347cf10a
      Dave Airlie 提交于
      this stops the device from being deleted before all the dma-bufs
      on it are freed, this fixes an oops when you unplug a udl device while
      it has imported a buffer from another device.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      347cf10a
    • T
      net: mvneta: use devm_ioremap_resource() instead of of_iomap() · b5f3b75d
      Thomas Petazzoni 提交于
      The mvneta driver currently uses of_iomap(), which has two drawbacks:
      it doesn't request the resource, and it isn't devm-style so some error
      handling is needed.
      
      This commit switches to use devm_ioremap_resource() instead, which
      automatically requests the resource (so the I/O registers region shows
      up properly in /proc/iomem), and also is devm-style, which allows to
      get rid of some error handling to unmap the I/O registers region.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5f3b75d
    • T
      net: mvneta: fix usage as a module on RGMII configurations · e3a8786c
      Thomas Petazzoni 提交于
      Commit 5445eaf3 ('mvneta: Try to fix mvneta when compiled as
      module') fixed the mvneta driver to make it work properly when loaded
      as a module in SGMII configuration, which was tested successful by the
      author on the Armada XP OpenBlocks AX3, which uses SGMII.
      
      However, it turns out that the Armada XP GP, which uses RGMII, is
      affected by a similar problem: its SERDES configuration is lost when
      mvneta is loaded as a module, because this configuration is set by the
      bootloader, and then lost because the clock is gated by the clock
      framework until the mvneta driver is loaded again and the clock is
      re-enabled.
      
      However, it turns out that for the RGMII case, setting the SERDES
      configuration is not sufficient: the PCS enable bit in the
      MVNETA_GMAC_CTRL_2 register must also be set, like in the SGMII
      configuration.
      
      Therefore, this commit reworks the SGMII/RGMII initialization: the
      only difference between the two now is a different SERDES
      configuration, all the rest is identical.
      
      In detail, to achieve this, the commit:
      
       * Renames MVNETA_SGMII_SERDES_CFG to MVNETA_SERDES_CFG because it is
         not specific to SGMII, but also used on RGMII configurations.
      
       * Adds a MVNETA_RGMII_SERDES_PROTO definition, that must be used as
         the MVNETA_SERDES_CFG value in RGMII configurations.
      
       * Removes the mvneta_gmac_rgmii_set() and mvneta_port_sgmii_config()
         functions, and instead directly do the SGMII/RGMII configuration in
         mvneta_port_up(), from where those functions where called. It is
         worth mentioning that mvneta_gmac_rgmii_set() had an 'enable'
         parameter that was always passed as '1', so it was pretty useless.
      
       * Reworks the mvneta_port_up() function to set the MVNETA_SERDES_CFG
         register to the appropriate value depending on the RGMII vs. SGMII
         configuration. It also unconditionally set the PCS_ENABLE bit (was
         already done for SGMII, but is now also needed for RGMII), and sets
         the PORT_RGMII bit (which was already done for both SGMII and
         RGMII).
      
      This commit was successfully tested with mvneta compiled as a module,
      on both the OpenBlocks AX3 (SGMII configuration) and the Armada XP GP
      (RGMII configuration).
      Reported-by: NSteve McIntyre <steve@einval.com>
      Cc: stable@vger.kernel.org # 3.11.x: 5445eaf3 mvneta: Try to fix mvneta when compiled as module
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3a8786c
    • T
      net: mvneta: rename MVNETA_GMAC2_PSC_ENABLE to MVNETA_GMAC2_PCS_ENABLE · a79121d3
      Thomas Petazzoni 提交于
      Bit 3 of the MVNETA_GMAC_CTRL_2 is actually used to enable the PCS,
      not the PSC: there was a typo in the name of the define, which this
      commit fixes.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a79121d3