Skip to content

L
linux
Switch branch/tag
  1. 23 Apr, 2013 1 commit
    • Axel Lin's avatar
      regulator: tps80031: Fix LDO2 track mode for TPS80031 or TPS80032-ES1.0 · 58fa6ab4
      Axel Lin authored 
      Currently we have a special code in tps80031_ldo_set_voltage_sel() to handle
LDO2 track mode for TPS80031 or TPS80032-ES1.0. The purpose is to address below
issues:

Issue description:
- LDO2 traking mode is enabled
- LDO2 tracks SMPS2 voltage.
- LDO2 automatically switch-off when LDO2_CFG_VOLTAGE is changed to some discrete values (non exhaustive list):
            00011001, 00011010, 00011011, 00011100, .
- LDO2 switch-on again when LDO2_CFG_VOLTAGE is changed to other values (non exhaustive list):
        00011000, 00010111, .

LDOs have reserved codes. For these codes, LDO is switch-off.

In tracking, LDO2 ref comes from SMPS2.
However LDO2 enable is still gated by LDO2 VSEL decoding.
As a result, in tracking mode LDO2 will be disabled for following code (SMPS VSEL format):
000000 & 100000 (MSB not decoded)
011001 & 111001 (MSB not decoded)
011010 & 111010 (MSB not decoded)
011100 & 111100 (MSB not decoded)
011101 & 111101 (MSB not decoded)
011110 & 111110 (MSB not decoded)

However, current code has below bugs:
1. It uses regulator_list_voltage_linear, so list_voltage() still shows above
   invalid selectors have supported voltage.
2. Current code may return -EINVAL in tps80031_ldo_set_voltage_sel() for
   supported voltage. This is because when we use regulator_list_voltage_linear
   as list_voltage callback, regulator core will default use
   regulator_map_voltage_linear(). regulator_map_voltage_linear() has an
   assumption that the voltages are linear which is not true for this case.

   For example,
   when request voltage range is: min_uV=950000 uV && max_uV=1200000 uV
   regulator_map_voltage_linear() returns the selector is 29 (0x1D),
   set_voltage_sel() returns -EINVAL.
   (The selector is in invalid range, 0x19 ~ 0x1f).

   In above case, map_voltage() should find the lowest valid voltage within
   specific range (selector = 0x20) and set_voltage_sel() should successfully
   set the voltage to 987500 uV.

This patch fixes these issues by:
1. Add checking valid setting for LDO2 track mode of TPS80031 or TPS80032-ES1.0
   in list_voltage.  So it returns -EINVAL for invalid selectors.
2. Implement tps80031_ldo_map_voltage, use regulator_map_voltage_iterate()
   to find the lowest voltage within specific range for TPS80031 or
   TPS80032-ES1.0. This is required when the voltage map is no longer linear.
Signed-off-by: default avatarAxel Lin <axel.lin@ingics.com>
Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      58fa6ab4
  3. 15 Apr, 2013 1 commit
  5. 14 Apr, 2013 10 commits
  7. 13 Apr, 2013 3 commits
    • Suleiman Souhlal's avatar
      vfs: Revert spurious fix to spinning prevention in prune_icache_sb · 5b55d708
      Suleiman Souhlal authored 
      Revert commit 62a3ddef ("vfs: fix spinning prevention in prune_icache_sb").

This commit doesn't look right: since we are looking at the tail of the
list (sb->s_inode_lru.prev) if we want to skip an inode, we should put
it back at the head of the list instead of the tail, otherwise we will
keep spinning on it.

Discovered when investigating why prune_icache_sb came top in perf
reports of a swapping load.
Signed-off-by: default avatarSuleiman Souhlal <suleiman@google.com>
Signed-off-by: default avatarHugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org # v3.2+
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5b55d708
    • Linus Torvalds's avatar
      kobject: fix kset_find_obj() race with concurrent last kobject_put() · a49b7e82
      Linus Torvalds authored 
      Anatol Pomozov identified a race condition that hits module unloading
and re-loading.  To quote Anatol:

 "This is a race codition that exists between kset_find_obj() and
  kobject_put().  kset_find_obj() might return kobject that has refcount
  equal to 0 if this kobject is freeing by kobject_put() in other
  thread.

  Here is timeline for the crash in case if kset_find_obj() searches for
  an object tht nobody holds and other thread is doing kobject_put() on
  the same kobject:

    THREAD A (calls kset_find_obj())     THREAD B (calls kobject_put())
    splin_lock()
                                         atomic_dec_return(kobj->kref), counter gets zero here
                                         ... starts kobject cleanup ....
                                         spin_lock() // WAIT thread A in kobj_kset_leave()
    iterate over kset->list
    atomic_inc(kobj->kref) (counter becomes 1)
    spin_unlock()
                                         spin_lock() // taken
                                         // it does not know that thread A increased counter so it
                                         remove obj from list
                                         spin_unlock()
                                         vfree(module) // frees module object with containing kobj

    // kobj points to freed memory area!!
    kobject_put(kobj) // OOPS!!!!

  The race above happens because module.c tries to use kset_find_obj()
  when somebody unloads module.  The module.c code was introduced in
  commit 6494a93d"

Anatol supplied a patch specific for module.c that worked around the
problem by simply not using kset_find_obj() at all, but rather than make
a local band-aid, this just fixes kset_find_obj() to be thread-safe
using the proper model of refusing the get a new reference if the
refcount has already dropped to zero.

See examples of this proper refcount handling not only in the kref
documentation, but in various other equivalent uses of this pattern by
grepping for atomic_inc_not_zero().

[ Side note: the module race does indicate that module loading and
  unloading is not properly serialized wrt sysfs information using the
  module mutex.  That may require further thought, but this is the
  correct fix at the kobject layer regardless. ]
Reported-analyzed-and-tested-by: default avatarAnatol Pomozov <anatol.pomozov@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a49b7e82
    • Josef Bacik's avatar
      Btrfs: make sure nbytes are right after log replay · 4bc4bee4
      Josef Bacik authored 
      While trying to track down a tree log replay bug I noticed that fsck was always
complaining about nbytes not being right for our fsynced file.  That is because
the new fsync stuff doesn't wait for ordered extents to complete, so the inodes
nbytes are not necessarily updated properly when we log it.  So to fix this we
need to set nbytes to whatever it is on the inode that is on disk, so when we
replay the extents we can just add the bytes that are being added as we replay
the extent.  This makes it work for the case that we have the wrong nbytes or
the case that we logged everything and nbytes is actually correct.  With this
I'm no longer getting nbytes errors out of btrfsck.

Cc: stable@vger.kernel.org
Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
Signed-off-by: default avatarChris Mason <chris.mason@fusionio.com>
      4bc4bee4
  9. 12 Apr, 2013 20 commits
  11. 11 Apr, 2013 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7