This provides a reliable way for asm-generic/types.h and other
files to find out if it is running on a 32 or 64 bit platform.

We cannot use CONFIG_64BIT for this in headers that are included
from user space because CONFIG symbols are not available there.
We also cannot do it inside of asm/types.h because some headers
need the word size but cannot include types.h.

The solution is to introduce a new header <asm/bitsperlong.h>
that defines both __BITS_PER_LONG for user space and
BITS_PER_LONG for usage in the kernel. The asm-generic
version falls back to 32 bit unless the architecture overrides
it, which I did for all 64 bit platforms.
Signed-off-by: NRemis Lima Baima <remis.developer@googlemail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The variable ccount_nsec has been renamed to nsec_per_ccount
in arch/xtensa/kernel/time.c in 2b8aea74 (2007-08-05),
but the fix failed to rename the variable in
arch/xtensa/include/asm/timex.h as well.
Signed-off-by: NOskar Schirmer <os@emlix.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

We need to add a "memory" dependency (barrier) in assembly macros
that access (read or write) memory. Otherwise, the compiler might
ill-optimize the order of memory accesses.
Signed-off-by: NChris Zankel <chris@zankel.net>

platform_get/set_rtc_time() is not implemented by any of the supported
xtensa platforms.  Remove the facility completely.

The initial seconds for xtime come from read_persistent_clock() which
returns just 0 in the generic implementation.  Platforms that sport a
persistent clock can implement this function.

This is needed to implement the ccount as a clock source.
Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
Signed-off-by: NChris Zankel <chris@zankel.net>

Support for the Stretch S6000 Xtensa core variant.
Signed-off-by: NJohannes Weiner <jw@emlix.com>
Signed-off-by: NOskar Schirmer <os@emlix.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

Allow the core variant code to provide irq enable/disable callbacks.
Signed-off-by: NJohannes Weiner <jw@emlix.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

Add support for !CONFIG_MMU setups.
Signed-off-by: NJohannes Weiner <jw@emlix.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

Add the arch-specific header for flat support on xtensa in preparation
for the Xtensa S6000 nommu port.
Signed-off-by: NOskar Schirmer <os@emlix.com>
Signed-off-by: NJohannes Weiner <jw@emlix.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

XCHAL_DATA_WIDTH is the maximum register width, slab caches should be
aligned to this.

Theoretical fix as all variants have had an XCHAL_DATA_WIDTH of 4
(wordsize) for now.  But the S6000 variant will raise this to 16.
Signed-off-by: NOskar Schirmer <os@emlix.com>
Signed-off-by: NJohannes Weiner <jw@emlix.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

The current assumption of the memory code is that the first RAM PFN in
the system is 0.

Adjust the relevant code to play well with setups where memory starts
at higher addresses, indicated by PLATFORM_DEFAULT_MEM_START.

The new memory model looks like this:

+----------+--+----------------------+----------------+
|          |  |                      |                |
|          |  |         RAM          |                |
|          |  |                      |                |
+----------+--+----------------------+----------------+
|          |  |                      |                |
+- PFN 0   |  +- min_low_pfn         +- max_low_pfn   +- max_pfn
           |
           +- ARCH_PFN_OFFSET
           +- PLATFORM_DEFAULT_MEM_START >> PAGE_SIZE

The memory map contains pages starting from pfn ARCH_PFN_OFFSET up to
max_low_pfn.  The only zone used right now will span exactly the same
region.

Usually, ARCH_PFN_OFFSET and min_low_pfn are the same value.  Handle
them separately for robustness.  Gapping pages will be in the memory
map but marked as reserved and won't be touched.
Signed-off-by: NJohannes Weiner <jw@emlix.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

This constant is defined in all core headers.  Remove the redundant
definition which might error out if other includes lead to inclusion
of <variant/core.h>.
Signed-off-by: NJohannes Weiner <jw@emlix.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

The current definition of CALLER_ADDRx isn't suitable for all platforms.
E.g. for ARM __builtin_return_address(N) doesn't work for N > 0 and
AFAIK for powerpc there are no frame pointers needed to have a working
__builtin_return_address.  This patch allows defining the CALLER_ADDRx
macros in <asm/ftrace.h> and let these take precedence.

Because now <asm/ftrace.h> is included unconditionally in
<linux/ftrace.h> all archs that don't already had this include get an
empty one for free.
Signed-off-by: NUwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>
Reviewed-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>

User space can request hardware and/or software time stamping.
Reporting of the result(s) via a new control message is enabled
separately for each field in the message because some of the
fields may require additional computation and thus cause overhead.
User space can tell the different kinds of time stamps apart
and choose what suits its needs.

When a TX timestamp operation is requested, the TX skb will be cloned
and the clone will be time stamped (in hardware or software) and added
to the socket error queue of the skb, if the skb has a socket
associated with it.

The actual TX timestamp will reach userspace as a RX timestamp on the
cloned packet. If timestamping is requested and no timestamping is
done in the device driver (potentially this may use hardware
timestamping), it will be done in software after the device's
start_hard_xmit routine.
Signed-off-by: NPatrick Ohly <patrick.ohly@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

fix the following 'make headers_check' warnings:

  usr/include/asm-xtensa/swab.h:14: include of <linux/types.h> is preferred over <asm/types.h>
  usr/include/asm-xtensa/swab.h:19: found __[us]{8,16,32,64} type without #include <linux/types.h>
Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>

Add swab.h to kbuild.asm and remove the individual entries from
each arch, mark as unifdef as some arches have some kernel-only
bits inside.
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixes compile breakage as linux/byteorder.h was removed.
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Rely on byteorder.h checking for endianness.
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

Move all header files for xtensa to arch/xtensa/include and platform and
variant header files to the appropriate arch/xtensa/platforms/ and
arch/xtensa/variants/ directories.

Moving the files gets also rid of all uses of symlinks in the Makefile.

This has been completed already for the majority of the architectures
and xtensa is one out of six missing.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NChris Zankel <chris@zankel.net>