linux/arch/tile/include, branch v2.6.37

arch/tile: handle rt_sigreturn() more cleanly

2010-12-17T21:59:29Z

The current tile rt_sigreturn() syscall pattern uses the common idiom of loading up pt_regs with all the saved registers from the time of the signal, then anticipating the fact that we will clobber the ABI "return value" register (r0) as we return from the syscall by setting the rt_sigreturn return value to whatever random value was in the pt_regs for r0. However, this breaks in our 64-bit kernel when running "compat" tasks, since we always sign-extend the "return value" register to properly handle returned pointers that are in the upper 2GB of the 32-bit compat address space. Doing this to the sigreturn path then causes occasional random corruption of the 64-bit r0 register. Instead, we stop doing the crazy "load the return-value register" hack in sigreturn. We already have some sigreturn-specific assembly code that we use to pass the pt_regs pointer to C code. We extend that code to also set the link register to point to a spot a few instructions after the usual syscall return address so we don't clobber the saved r0. Now it no longer matters what the rt_sigreturn syscall returns, and the pt_regs structure can be cleanly and completely reloaded. Signed-off-by: Chris Metcalf

Merge branch 'drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile

2010-11-24T22:42:03Z

* 'drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: pci root complex: support for tile architecture drivers/net/tile/: on-chip network drivers for the tile architecture MAINTAINERS: add drivers/char/hvc_tile.c as maintained by tile

pci root complex: support for tile architecture

2010-11-24T18:13:49Z

This change enables PCI root complex support for TILEPro. Unlike TILE-Gx, TILEPro has no support for memory-mapped I/O, so the PCI support consists of hypervisor upcalls for PIO, DMA, etc. However, the performance is fine for the devices we have tested with so far (1Gb Ethernet, SATA, etc.). The header was tweaked to be a little bit more aggressive about disabling attempts to map/unmap IO port space. The hacky header was rolled into the header and the result was simplified. Both of the latter two headers were preliminary versions not meant for release before now - oh well. There is one quirk for our TILEmpower platform, which accidentally negotiates up to 5GT and needs to be kicked down to 2.5GT. Signed-off-by: Chris Metcalf

drivers/net/tile/: on-chip network drivers for the tile architecture

2010-11-24T18:11:18Z

This change adds the first network driver for the tile architecture, supporting the on-chip XGBE and GBE shims. The infrastructure is present for the TILE-Gx networking drivers (another three source files in the new directory) but for now the the actual tilegx sources are waiting on releasing hardware to initial customers. Note that arch/tile/include/hv/* are "upstream" headers from the Tilera hypervisor and will probably benefit less from LKML review. Signed-off-by: Chris Metcalf

asm-generic/stat.h: support 64-bit file time_t for stat()

2010-11-01T19:31:29Z

The existing asm-generic/stat.h specifies st_mtime, etc., as a 32-value, and works well for 32-bit architectures (currently microblaze, score, and 32-bit tile). However, for 64-bit architectures it isn't sufficient to return 32 bits of time_t; this isn't good insurance against the 2037 rollover. (It also makes glibc support less convenient, since we can't use glibc's handy STAT_IS_KERNEL_STAT mode.) This change extends the two "timespec" fields for each of the three atime, mtime, and ctime fields from "int" to "long". As a result, on 32-bit platforms nothing changes, and 64-bit platforms will now work as expected. The only wrinkle is 32-bit userspace under 64-bit kernels taking advantage of COMPAT mode. For these, we leave the "struct stat64" definitions with the "int" versions of the time_t and nsec fields, so that architectures can implement compat_sys_stat64() and friends with sys_stat64(), etc., and get the expected 32-bit structure layout. This requires a field-by-field copy in the kernel, implemented by the code guarded under __ARCH_WANT_STAT64. This does mean that the shape of the "struct stat" and "struct stat64" structures is different on a 64-bit kernel, but only one of the two structures should ever be used by any given process: "struct stat" is meant for 64-bit userspace only, and "struct stat64" for 32-bit userspace only. (On a 32-bit kernel the two structures continue to have the same shape, since "long" is 32 bits.) The alternative is keeping the two structures the same shape on 64-bit kernels, which means a 64-bit time_t in "struct stat64" for 32-bit processes. This is a little unnatural since 32-bit userspace can't do anything with 64 bits of time_t information, since time_t is just "long", not "int64_t"; and in any case 32-bit userspace might expect to be running under a 32-bit kernel, which can't provide the high 32 bits anyway. In the case of a 32-bit kernel we'd then be extending the kernel's 32-bit time_t to 64 bits, then truncating it back to 32 bits again in userspace, for no particular reason. And, as mentioned above, if we have 64-bit time_t for 32-bit processes we can't easily use glibc's STAT_IS_KERNEL_STAT, since glibc's stat structure requires an embedded "struct timespec", which is a pair of "long" (32-bit) values in a 32-bit userspace. "Inventive" solutions are possible, but are pretty hacky. Signed-off-by: Chris Metcalf Acked-by: Arnd Bergmann

arch/tile: complete migration to new kmap_atomic scheme

2010-11-01T19:30:36Z

This change makes KM_TYPE_NR independent of the actual deprecated list of km_type values, which are no longer used in tile code anywhere. For now we leave it set to 8, allowing that many nested mappings, and thus reserving 32MB of address space. A few remaining places using KM_* values were cleaned up as well. Signed-off-by: Chris Metcalf

Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile

2010-10-27T00:25:38Z

* git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: arch/tile: convert a BUG_ON to BUILD_BUG_ON arch/tile: make ptrace() work properly for TILE-Gx COMPAT mode arch/tile: support new info op generated by compiler arch/tile: minor whitespace/naming changes for string support files arch/tile: enable single-step support for TILE-Gx arch/tile: parameterize system PLs to support KVM port arch/tile: add Tilera's header as an open-source header arch/tile: Bomb C99 comments to C89 comments in tile's arch/tile: prevent corrupt top frame from causing backtracer runaway arch/tile: various top-level Makefile cleanups arch/tile: change lower bound on syscall error return to -4095 arch/tile: properly export __mb_incoherent for modules arch/tile: provide a definition of MAP_STACK kmemleak: add TILE to the list of supported architectures. char: hvc: check for error case arch/tile: Add a warning if we try to allocate too much vmalloc memory. arch/tile: update some comments to clarify register usage. arch/tile: use better "punctuation" for VMSPLIT_3_5G and friends arch/tile: Use tile: replace some BUG_ON checks with BUILD_BUG_ON checks

mm: remove pte_*map_nested()

2010-10-26T23:52:08Z

Since we no longer need to provide KM_type, the whole pte_*map_nested() API is now redundant, remove it. Signed-off-by: Peter Zijlstra Acked-by: Chris Metcalf Cc: David Howells Cc: Hugh Dickins Cc: Rik van Riel Cc: Ingo Molnar Cc: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Steven Rostedt Cc: Russell King Cc: Ralf Baechle Cc: David Miller Cc: Paul Mackerras Cc: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mm: stack based kmap_atomic()

2010-10-26T23:52:08Z

Keep the current interface but ignore the KM_type and use a stack based approach. The advantage is that we get rid of crappy code like: #define __KM_PTE \ (in_nmi() ? KM_NMI_PTE : \ in_irq() ? KM_IRQ_PTE : \ KM_PTE0) and in general can stop worrying about what context we're in and what kmap slots might be appropriate for that. The downside is that FRV kmap_atomic() gets more expensive. For now we use a CPP trick suggested by Andrew: #define kmap_atomic(page, args...) __kmap_atomic(page) to avoid having to touch all kmap_atomic() users in a single patch. [ not compiled on: - mn10300: the arch doesn't actually build with highmem to begin with ] [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c] Acked-by: Rik van Riel Signed-off-by: Peter Zijlstra Acked-by: Chris Metcalf Cc: David Howells Cc: Hugh Dickins Cc: Ingo Molnar Cc: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Steven Rostedt Cc: Russell King Cc: Ralf Baechle Cc: David Miller Cc: Paul Mackerras Cc: Benjamin Herrenschmidt Cc: Dave Airlie Cc: Li Zefan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic

2010-10-22T18:17:06Z

* git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: asm-generic/io.h: allow people to override individual funcs bitops: remove duplicated extern declarations bitops: make asm-generic/bitops/find.h more generic asm-generic: kdebug.h: Checkpatch cleanup asm-generic: fcntl: make exported headers use strict posix types asm-generic: cmpxchg does not handle non-long arguments asm-generic: make atomic_add_unless a function