Eric Lee / linux-smarc-t335x-v3.2

26 May, 2010

1 commit

  • 13da9e200   Revert "endian: #define __BYTE_ORDER" ... Browse Code »

    This reverts commit b3b77c8caef1750ebeea1054e39e358550ea9f55, which was
    also totally broken (see commit 0d2daf5cc858 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
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

25 May, 2010

1 commit

  • b3b77c8ca   endian: #define __BYTE_ORDER ... Browse Code »

    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
    Cc: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joakim Tjernlund
     

11 Dec, 2009

1 commit

05 Dec, 2008

3 commits

20 May, 2008

1 commit

04 Apr, 2006

1 commit

  • b46da0567   kbuild: use relative path to -I ... Browse Code »

    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
     

31 Jan, 2006

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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!

    Linus Torvalds