* git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
  arch/tile: fix memchr() not to dereference memory for zero length
  arch/tile: make glibc's sysconf(_SC_NPROCESSORS_CONF) work correctly
  arch/tile: fix rwlock so would-be write lockers don't block new readers

* '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

glibc assumes that it can count /sys/devices/system/cpu/cpu* to get
the number of configured cpus.  For this to be valid on tile, we need
to generate a "cpu" entry for all cpus, including the ones that are
not currently allocated for Linux's use.

Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>

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 <asm/io.h> header was tweaked to be a little bit more aggressive
about disabling attempts to map/unmap IO port space.  The hacky
<asm/pci-bridge.h> header was rolled into the <asm/pci.h> 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 <cmetcalf@tilera.com>

The big kernel lock has been removed from all these files at some point,
leaving only the #include.

Remove this too as a cleanup.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Arnd's recent patch series tagged this device with noop_llseek,
conservatively.  In fact, it should be no_llseek, which we arrange
for by opening the device with nonseekable_open().

Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>

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 <cmetcalf@tilera.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>

The kernel was allowing any component of the pt_regs to be updated either
by signal handlers writing to the stack, or by processes writing via
PTRACE_POKEUSR or PTRACE_SETREGS, which meant they could set their PL
up from 0 to 1 and get access to kernel code and data (or, in practice,
cause a kernel panic).  We now always reset the ex1 field, allowing the
user to set their ICS bit only.

Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>

This change is modelled on similar fixes for other architectures.
The pt_regs "faultnum" member is set to the trap (fault) number that
caused us to enter the kernel, and is INT_SWINT_1 for the syscall software
interrupt.  We already supported a pseudo value, INT_SWINT_1_SIGRETURN,
that we used for the rt_sigreturn syscall; it avoided the case where
one signal was handled, then we "tail-called" to another handler.

This change avoids the similar case where we start to call one handler,
then are preempted into another handler when we start trying to run
the first handler.  We clear ->faultnum after calling handle_signal(),
and to be paranoid also in the case where there was no signal to deliver.

Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>

This completes the tile migration to the new naming scheme for
the architecture-specific irq management code.

Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>