1. 03 6月, 2013 1 次提交
  2. 25 5月, 2013 1 次提交
  3. 23 5月, 2013 1 次提交
  4. 12 5月, 2013 4 次提交
  5. 01 5月, 2013 2 次提交
  6. 30 4月, 2013 4 次提交
  7. 16 4月, 2013 1 次提交
    • S
      regmap: don't corrupt work buffer in _regmap_raw_write() · 5a08d156
      Stephen Warren 提交于
      _regmap_raw_write() contains code to call regcache_write() to write
      values to the cache. That code calls memcpy() to copy the value data to
      the start of the work_buf. However, at least when _regmap_raw_write() is
      called from _regmap_bus_raw_write(), the value data is in the work_buf,
      and this memcpy() operation may over-write part of that value data,
      depending on the value of reg_bytes + pad_bytes. At least when using
      reg_bytes==1 and pad_bytes==0, corruption of the value data does occur.
      
      To solve this, remove the memcpy() operation, and modify the subsequent
      .parse_val() call to parse the original value buffer directly.
      
      At least in the case of 8-bit register address and 16-bit values, and
      writes of single registers at a time, this memcpy-then-parse combination
      used to cancel each-other out; for a work-buffer containing xx 89 03,
      the memcpy changed it to 89 03 03, and the parse_val changed it back to
      89 89 03, thus leaving the value uncorrupted. This appears completely
      accidental though. Since commit 8a819ff8 "regmap: core: Split out in
      place value parsing", .parse_val only returns the parsed value, and does
      not modify the buffer, and hence does not (accidentally) undo the
      corruption caused by memcpy(). This caused bogus values to get written
      to HW, thus preventing e.g. audio playback on systems with a WM8903
      CODEC. This patch fixes that.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      5a08d156
  8. 12 4月, 2013 5 次提交
  9. 11 4月, 2013 2 次提交
  10. 10 4月, 2013 1 次提交
    • M
      regmap: Back out work buffer fix · 51a246aa
      Mark Brown 提交于
      This reverts commit bc8ce4 (regmap: don't corrupt work buffer in
      _regmap_raw_write()) since it turns out that it can cause issues when
      taken in isolation from the other changes in -next that lead to its
      discovery.  On the basis that nobody noticed the problems for quite some
      time without that subsequent work let's drop it from v3.9.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      51a246aa
  11. 08 4月, 2013 1 次提交
    • K
      driver core: add uid and gid to devtmpfs · 3c2670e6
      Kay Sievers 提交于
      Some drivers want to tell userspace what uid and gid should be used for
      their device nodes, so allow that information to percolate through the
      driver core to userspace in order to make this happen.  This means that
      some systems (i.e.  Android and friends) will not need to even run a
      udev-like daemon for their device node manager and can just rely in
      devtmpfs fully, reducing their footprint even more.
      Signed-off-by: NKay Sievers <kay@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c2670e6
  12. 05 4月, 2013 3 次提交
  13. 04 4月, 2013 1 次提交
  14. 02 4月, 2013 1 次提交
    • R
      PM / QoS: Avoid possible deadlock related to sysfs access · 0f703069
      Rafael J. Wysocki 提交于
      Commit b81ea1b5 (PM / QoS: Fix concurrency issues and memory leaks in
      device PM QoS) put calls to pm_qos_sysfs_add_latency(),
      pm_qos_sysfs_add_flags(), pm_qos_sysfs_remove_latency(), and
      pm_qos_sysfs_remove_flags() under dev_pm_qos_mtx, which was a
      mistake, because it may lead to deadlocks in some situations.
      For example, if pm_qos_remote_wakeup_store() is run in parallel
      with dev_pm_qos_constraints_destroy(), they may deadlock in the
      following way:
      
       ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.9.0-rc4-next-20130328-sasha-00014-g91a3267 #319 Tainted: G        W
       -------------------------------------------------------
       trinity-child6/12371 is trying to acquire lock:
        (s_active#54){++++.+}, at: [<ffffffff81301631>] sysfs_addrm_finish+0x31/0x60
      
       but task is already holding lock:
        (dev_pm_qos_mtx){+.+.+.}, at: [<ffffffff81f07cc3>] dev_pm_qos_constraints_destroy+0x23/0x250
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (dev_pm_qos_mtx){+.+.+.}:
              [<ffffffff811811da>] lock_acquire+0x1aa/0x240
              [<ffffffff83dab809>] __mutex_lock_common+0x59/0x5e0
              [<ffffffff83dabebf>] mutex_lock_nested+0x3f/0x50
              [<ffffffff81f07f2f>] dev_pm_qos_update_flags+0x3f/0xc0
              [<ffffffff81f05f4f>] pm_qos_remote_wakeup_store+0x3f/0x70
              [<ffffffff81efbb43>] dev_attr_store+0x13/0x20
              [<ffffffff812ffdaa>] sysfs_write_file+0xfa/0x150
              [<ffffffff8127f2c1>] __kernel_write+0x81/0x150
              [<ffffffff812afc2d>] write_pipe_buf+0x4d/0x80
              [<ffffffff812af57c>] splice_from_pipe_feed+0x7c/0x120
              [<ffffffff812afa25>] __splice_from_pipe+0x45/0x80
              [<ffffffff812b14fc>] splice_from_pipe+0x4c/0x70
              [<ffffffff812b1538>] default_file_splice_write+0x18/0x30
              [<ffffffff812afae3>] do_splice_from+0x83/0xb0
              [<ffffffff812afb2e>] direct_splice_actor+0x1e/0x20
              [<ffffffff812b0277>] splice_direct_to_actor+0xe7/0x200
              [<ffffffff812b15bc>] do_splice_direct+0x4c/0x70
              [<ffffffff8127eda9>] do_sendfile+0x169/0x300
              [<ffffffff8127ff94>] SyS_sendfile64+0x64/0xb0
              [<ffffffff83db7d18>] tracesys+0xe1/0xe6
      
       -> #0 (s_active#54){++++.+}:
              [<ffffffff811800cf>] __lock_acquire+0x15bf/0x1e50
              [<ffffffff811811da>] lock_acquire+0x1aa/0x240
              [<ffffffff81300aa2>] sysfs_deactivate+0x122/0x1a0
              [<ffffffff81301631>] sysfs_addrm_finish+0x31/0x60
              [<ffffffff812ff77f>] sysfs_hash_and_remove+0x7f/0xb0
              [<ffffffff813035a1>] sysfs_unmerge_group+0x51/0x70
              [<ffffffff81f068f4>] pm_qos_sysfs_remove_flags+0x14/0x20
              [<ffffffff81f07490>] __dev_pm_qos_hide_flags+0x30/0x70
              [<ffffffff81f07cd5>] dev_pm_qos_constraints_destroy+0x35/0x250
              [<ffffffff81f06931>] dpm_sysfs_remove+0x11/0x50
              [<ffffffff81efcf6f>] device_del+0x3f/0x1b0
              [<ffffffff81efd128>] device_unregister+0x48/0x60
              [<ffffffff82d4083c>] usb_hub_remove_port_device+0x1c/0x20
              [<ffffffff82d2a9cd>] hub_disconnect+0xdd/0x160
              [<ffffffff82d36ab7>] usb_unbind_interface+0x67/0x170
              [<ffffffff81f001a7>] __device_release_driver+0x87/0xe0
              [<ffffffff81f00559>] device_release_driver+0x29/0x40
              [<ffffffff81effc58>] bus_remove_device+0x148/0x160
              [<ffffffff81efd07f>] device_del+0x14f/0x1b0
              [<ffffffff82d344f9>] usb_disable_device+0xf9/0x280
              [<ffffffff82d34ff8>] usb_set_configuration+0x268/0x840
              [<ffffffff82d3a7fc>] usb_remove_store+0x4c/0x80
              [<ffffffff81efbb43>] dev_attr_store+0x13/0x20
              [<ffffffff812ffdaa>] sysfs_write_file+0xfa/0x150
              [<ffffffff8127f71d>] do_loop_readv_writev+0x4d/0x90
              [<ffffffff8127f999>] do_readv_writev+0xf9/0x1e0
              [<ffffffff8127faba>] vfs_writev+0x3a/0x60
              [<ffffffff8127fc60>] SyS_writev+0x50/0xd0
              [<ffffffff83db7d18>] tracesys+0xe1/0xe6
      
       other info that might help us debug this:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(dev_pm_qos_mtx);
                                      lock(s_active#54);
                                      lock(dev_pm_qos_mtx);
         lock(s_active#54);
      
        *** DEADLOCK ***
      
      To avoid that, remove the calls to functions mentioned above from
      under dev_pm_qos_mtx and introduce a separate lock to prevent races
      between functions that add or remove device PM QoS sysfs attributes
      from happening.
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0f703069
  15. 30 3月, 2013 7 次提交
  16. 27 3月, 2013 5 次提交
新手
引导
客服 返回
顶部