1. 24 6月, 2013 1 次提交
  2. 17 6月, 2013 1 次提交
  3. 13 6月, 2013 3 次提交
  4. 12 6月, 2013 2 次提交
  5. 09 6月, 2013 1 次提交
  6. 08 6月, 2013 1 次提交
  7. 07 6月, 2013 1 次提交
  8. 06 6月, 2013 1 次提交
  9. 01 6月, 2013 3 次提交
    • M
      powerpc/tm: Fix userspace stack corruption on signal delivery for active transactions · 2b3f8e87
      Michael Neuling 提交于
      When in an active transaction that takes a signal, we need to be careful with
      the stack.  It's possible that the stack has moved back up after the tbegin.
      The obvious case here is when the tbegin is called inside a function that
      returns before a tend.  In this case, the stack is part of the checkpointed
      transactional memory state.  If we write over this non transactionally or in
      suspend, we are in trouble because if we get a tm abort, the program counter
      and stack pointer will be back at the tbegin but our in memory stack won't be
      valid anymore.
      
      To avoid this, when taking a signal in an active transaction, we need to use
      the stack pointer from the checkpointed state, rather than the speculated
      state.  This ensures that the signal context (written tm suspended) will be
      written below the stack required for the rollback.  The transaction is aborted
      becuase of the treclaim, so any memory written between the tbegin and the
      signal will be rolled back anyway.
      
      For signals taken in non-TM or suspended mode, we use the
      normal/non-checkpointed stack pointer.
      
      Tested with 64 and 32 bit signals
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2b3f8e87
    • M
      powerpc/tm: Abort on emulation and alignment faults · 6ce6c629
      Michael Neuling 提交于
      If we are emulating an instruction inside an active user transaction that
      touches memory, the kernel can't emulate it as it operates in transactional
      suspend context.  We need to abort these transactions and send them back to
      userspace for the hardware to rollback.
      
      We can service these if the user transaction is in suspend mode, since the
      kernel will operate in the same suspend context.
      
      This adds a check to all alignment faults and to specific instruction
      emulations (only string instructions for now).  If the user process is in an
      active (non-suspended) transaction, we abort the transaction go back to
      userspace allowing the HW to roll back the transaction and tell the user of the
      failure.  This also adds new tm abort cause codes to report the reason of the
      persistent error to the user.
      
      Crappy test case here http://neuling.org/devel/junkcode/aligntm.cSigned-off-by: NMichael Neuling <mikey@neuling.org>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6ce6c629
    • M
      powerpc/tm: Update cause codes documentation · 24b92375
      Michael Neuling 提交于
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Cc: <stable@vger.kernel.org> # 3.9 only
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      24b92375
  10. 25 5月, 2013 4 次提交
  11. 21 5月, 2013 2 次提交
  12. 20 5月, 2013 1 次提交
  13. 17 5月, 2013 1 次提交
  14. 15 5月, 2013 3 次提交
  15. 14 5月, 2013 4 次提交
  16. 13 5月, 2013 3 次提交
  17. 09 5月, 2013 1 次提交
  18. 08 5月, 2013 3 次提交
  19. 07 5月, 2013 1 次提交
  20. 04 5月, 2013 2 次提交
    • J
      hwmon: (lm75) Add support for the Dallas/Maxim DS7505 · 3fbc81e3
      Jean Delvare 提交于
      Basically it's the same as the original DS75 but much faster.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NGuenter Roeck <linux@roeck-us.net>
      3fbc81e3
    • J
      hwmon: (lm75) Tune resolution and sample time per chip · 0cd2c72d
      Jean Delvare 提交于
      Most LM75-compatible chips can either sample much faster or with a
      much better resolution than the original LM75 chip. So far the lm75
      driver did not let the user take benefit of these improvements. Do it
      now.
      
      I decided to almost always configure the chip to use the best
      resolution possible, which also means the longest sample time. The
      only chips for which I didn't are the DS75, DS1775 and STDS75, because
      they are really too slow in 12-bit mode (1.2 to 1.5 second worst case)
      so I went for 11-bit mode as a more reasonable tradeoff. This choice is
      dictated by the fact that the hwmon subsystem is meant for system
      monitoring, it has never been supposed to be ultra-fast, and as a
      matter of fact we do cache the sampled values in almost all drivers.
      
      If anyone isn't pleased with these default settings, they can always
      introduce a platform data structure or DT support for the lm75. That
      being said, it seems nobody ever complained that the driver wouldn't
      refresh the value faster than every 1.5 second, and the change made
      it faster for all chips even in 12-bit mode, so I don't expect any
      complaint.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NGuenter Roeck <linux@roeck-us.net>
      0cd2c72d
  21. 02 5月, 2013 1 次提交