Commit Graph

11 Commits (a26ac2455ffcf3be5c6ef92bc6df7182700f2114)

Author SHA1 Message Date
Lucas De Marchi 25985edced Fix common misspellings
Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-31 11:26:23 -03:00
Linus Torvalds 13da9e200f Revert "endian: #define __BYTE_ORDER"
This reverts commit b3b77c8cae, which was
also totally broken (see commit 0d2daf5cc8 that reverted the crc32
version of it).  As reported by Stephen Rothwell, it causes problems on
big-endian machines:

> In file included from fs/jfs/jfs_types.h:33,
>                  from fs/jfs/jfs_incore.h:26,
>                  from fs/jfs/file.c:22:
> fs/jfs/endian24.h:36:101: warning: "__LITTLE_ENDIAN" is not defined

The kernel has never had that crazy "__BYTE_ORDER == __LITTLE_ENDIAN"
model.  It's not how we do things, and it isn't how we _should_ do
things.  So don't go there.

Requested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 08:30:15 -07:00
Joakim Tjernlund b3b77c8cae endian: #define __BYTE_ORDER
Linux does not define __BYTE_ORDER in its endian header files which makes
some header files bend backwards to get at the current endian.  Lets
#define __BYTE_ORDER in big_endian.h/litte_endian.h to make it easier for
header files that are used in user space too.

In userspace the convention is that

  1. _both_ __LITTLE_ENDIAN and __BIG_ENDIAN are defined,
  2. you have to test for e.g. __BYTE_ORDER == __BIG_ENDIAN.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-25 08:07:02 -07:00
David S. Miller 121dd5f277 sparc: Add alignment and emulation fault perf events.
This mirrors commit 196f02bf90
(powerpc: perf_event: Add alignment-faults and emulation-faults software events)

Signed-off-by: David S. Miller <davem@davemloft.net>
2009-12-11 01:07:53 -08:00
Sam Ravnborg 5115f39c20 sparc64: unify math-emu
Move relavent files to sparc/math-emu and
adjust path/include accordingly.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-12-04 09:16:56 -08:00
Sam Ravnborg 774434bf33 sparc: prepare math-emu for unification
Add _32 to filenames to make them 32 bit unique

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-12-04 09:16:56 -08:00
Sam Ravnborg d59b3706a9 sparc: cleanup math-emu
- Drop unused assignment from Makefile
- Replace EXTRA_CFLAGS with ccflags-y
- Delete unused file

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-12-04 09:16:55 -08:00
Adrian Bunk 88278ca27a sparc: remove CVS keywords
This patch removes the CVS keywords that weren't updated for a long time
from comments.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-05-20 00:33:44 -07:00
Sam Ravnborg b46da0567d kbuild: use relative path to -I
Using a relative path has the advantage that when the kernel source
tree is moved the relevant .o files will not be rebuild just because
the path to the kernel src has changed.
This also got rid of a user of TOPDIR - which has been deprecated for a long time now.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-04-04 16:56:10 +02:00
David S. Miller 22f01da398 [SPARC]: Fix compile failures in math-emu.
Kill debugging default switch cases in do_one_mathemu().
That case is handled properly already and gcc hates
the empty statement that results when the debug code is
disabled.

Pointed out by kaffe.

Signed-off-by: David S. Miller <davem@davemloft.net>
2006-01-30 16:46:24 -08:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00