Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 6月, 2013 1 次提交
  3. 13 6月, 2013 1 次提交
  5. 08 6月, 2013 1 次提交
  7. 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
  11. 25 5月, 2013 2 次提交
    • S
      drivers/video: implement a simple framebuffer driver · 26549c8d
      由 Stephen Warren 提交于 
      A simple frame-buffer describes a raw memory region that may be rendered
to, with the assumption that the display hardware has already been set
up to scan out from that buffer.

This is useful in cases where a bootloader exists and has set up the
display hardware, but a Linux driver doesn't yet exist for the display
hardware.

Examples use-cases include:

* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
  devices, and likely many other ARM or embedded systems.  These cannot
  yet be supported using a full graphics driver, since the panel control
  should be provided by the CDF (Common Display Framework), which has been
  stuck in design/review for quite some time.  One could support these
  panels using custom SoC-specific code, but there is a desire to use
  common infra-structure rather than having each SoC vendor invent their
  own code, hence the desire to wait for CDF.

* Hardware for which a full graphics driver is not yet available, and
  the path to obtain one upstream isn't yet clear.  For example, the
  Raspberry Pi.

* Any hardware in early stages of upstreaming, before a full graphics
  driver has been tackled.  This driver can provide a graphical boot
  console (even full X support) much earlier in the upstreaming process,
  thus making new SoC or board support more generally useful earlier.

[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NOlof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26549c8d
    • A
      rapidio: documentation update for enumeration changes · 5eeb9293
      由 Alexandre Bounine 提交于 
      Update RapidIO documentation to reflect changes made to
enumeration/discovery build configuration and user space triggering
mechanism.
Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Andre van Herk <andre.van.herk@Prodrive.nl>
Cc: Micha Nelissen <micha.nelissen@Prodrive.nl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5eeb9293
  13. 17 5月, 2013 1 次提交
  15. 15 5月, 2013 3 次提交
  17. 14 5月, 2013 4 次提交
  19. 09 5月, 2013 1 次提交
  21. 08 5月, 2013 3 次提交
  23. 07 5月, 2013 1 次提交
  25. 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
  27. 02 5月, 2013 4 次提交
  29. 01 5月, 2013 3 次提交
  31. 30 4月, 2013 9 次提交