Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 08 10月, 2008 1 次提交
  3. 26 9月, 2008 2 次提交
    • D
      ARM: Delete ARM's own cnt32_to_63.h · bc173c57
      由 David Howells 提交于 
      Delete ARM's own cnt32_to_63.h as the copy in include/linux/ should now be
used instead.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bc173c57
    • J
      kgdb, x86, arm, mips, powerpc: ignore user space single stepping · d7161a65
      由 Jason Wessel 提交于 
      On the x86 arch, user space single step exceptions should be ignored
if they occur in the kernel space, such as ptrace stepping through a
system call.

First check if it is kgdb that is executing a single step, then ensure
it is not an accidental traversal into the user space, while in kgdb,
any other time the TIF_SINGLESTEP is set, kgdb should ignore the
exception.

On x86, arm, mips and powerpc, the kgdb_contthread usage was
inconsistent with the way single stepping is implemented in the kgdb
core.  The arch specific stub should always set the
kgdb_cpu_doing_single_step correctly if it is single stepping.  This
allows kgdb to correctly process an instruction steps if ptrace
happens to be requesting an instruction step over a system call.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      d7161a65
  5. 25 9月, 2008 1 次提交
  7. 18 9月, 2008 3 次提交
  9. 14 9月, 2008 3 次提交
  11. 11 9月, 2008 1 次提交
    • R
      [ARM] OMAP: Fix MMC device data · 7736c09c
      由 Russell King 提交于 
      OMAPs MMC device data was passing the wrong structure via the platform
device.  Moreover, a missing function means that both sx1_defconfig
and omap_h2_1610_defconfig builds failed with

	undefined reference to `omap_set_mmc_info'

errors.  Fix this by updating the MMC support from the omapzoom tree.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7736c09c
  13. 06 9月, 2008 2 次提交
    • L
      [ARM] 5241/1: provide ioremap_wc() · 1ad77a87
      由 Lennert Buytenhek 提交于 
      This patch provides an ARM implementation of ioremap_wc().

We use different page table attributes depending on which CPU we
are running on:

- Non-XScale ARMv5 and earlier systems: The ARMv5 ARM documents four
  possible mapping types (CB=00/01/10/11).  We can't use any of the
  cached memory types (CB=10/11), since that breaks coherency with
  peripheral devices.  Both CB=00 and CB=01 are suitable for _wc, and
  CB=01 (Uncached/Buffered) allows the hardware more freedom than
  CB=00, so we'll use that.

  (The ARMv5 ARM seems to suggest that CB=01 is allowed to delay stores
  but isn't allowed to merge them, but there is no other mapping type
  we can use that allows the hardware to delay and merge stores, so
  we'll go with CB=01.)

- XScale v1/v2 (ARMv5): same as the ARMv5 case above, with the slight
  difference that on these platforms, CB=01 actually _does_ allow
  merging stores.  (If you want noncoalescing bufferable behavior
  on Xscale v1/v2, you need to use XCB=101.)

- Xscale v3 (ARMv5) and ARMv6+: on these systems, we use TEXCB=00100
  mappings (Inner/Outer Uncacheable in xsc3 parlance, Uncached Normal
  in ARMv6 parlance).

  The ARMv6 ARM explicitly says that any accesses to Normal memory can
  be merged, which makes Normal memory more suitable for _wc mappings
  than Device or Strongly Ordered memory, as the latter two mapping
  types are guaranteed to maintain transaction number, size and order.
  We use the Uncached variety of Normal mappings for the same reason
  that we can't use C=1 mappings on ARMv5.

  The xsc3 Architecture Specification documents TEXCB=00100 as being
  Uncacheable and allowing coalescing of writes, which is also just
  what we need.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1ad77a87
    • D
      Revert "[ARM] use the new byteorder headers" · b35de672
      由 David Woodhouse 提交于 
      This reverts commit ae82cbfc. It
needs the new byteorder headers to be exported to userspace, and
they aren't yet -- and probably shouldn't be, at this point in the
2.6.27 release cycle (or ever, for that matter).
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b35de672
  15. 05 9月, 2008 1 次提交
  17. 04 9月, 2008 1 次提交
  19. 03 9月, 2008 1 次提交
  21. 02 9月, 2008 1 次提交
  23. 29 8月, 2008 1 次提交
  25. 28 8月, 2008 3 次提交
  27. 27 8月, 2008 9 次提交
  29. 26 8月, 2008 1 次提交
  31. 24 8月, 2008 1 次提交
  33. 23 8月, 2008 1 次提交
  35. 22 8月, 2008 4 次提交
  37. 21 8月, 2008 1 次提交
  39. 19 8月, 2008 1 次提交
  41. 18 8月, 2008 1 次提交