Eric Lee / smarc-fsl-linux-kernel

05 Aug, 2014

1 commit

  • 093758e3d   arch/sparc/math-emu/math_32.c: drop stray break operator ... Browse Code »

    This commit is a guesswork, but it seems to make sense to drop this
    break, as otherwise the following line is never executed and becomes
    dead code. And that following line actually saves the result of
    local calculation by the pointer given in function argument. So the
    proposed change makes sense if this code in the whole makes sense (but I
    am unable to analyze it in the whole).

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81641
    Reported-by: David Binderman
    Signed-off-by: Andrey Utkin
    Signed-off-by: David S. Miller

    Andrey Utkin
     

19 May, 2014

2 commits

  • 66a9df34e   sparc64: remove cast from output constraints in math asm statements ... Browse Code »

    The following asm statements generated a sparse warning:

    asm("addcc \n\t" : "=r" (((USItype)(r2)))

    warning: asm output is not an lvalue

    When asking on the sparse mailing list Linus replyed:

    "
    Those casts to (USItype) are all pointless to begin with (since the
    values are of that type already!) and they mean that the expression
    isn't something you can assign to (lvalue).
    "

    In the math emulation code drop all casts in the output
    parts of the asm statements.

    This fixes a lot of "warning: asm output is not an lvalue" sparse
    warnings in math_64.c.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     
  • 347b0cf02   sparc32: remove cast from output constraints in math asm statements ... Browse Code »

    The following asm statements generated a sparse warning:

    asm("addcc \n\t" : "=r" (((USItype)(r2)))

    warning: asm output is not an lvalue

    When asking on the sparse mailing list Linus replyed:

    "
    Those casts to (USItype) are all pointless to begin with (since the
    values are of that type already!) and they mean that the expression
    isn't something you can assign to (lvalue).
    "

    In the math emulation code drop all casts in the output
    parts of the asm statements.

    This fixes a lot of "warning: asm output is not an lvalue" sparse
    warnings in math_32.c.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

27 Oct, 2012

1 commit

  • 517ffce4e   sparc64: Make montmul/montsqr/mpmul usable in 32-bit threads. ... Browse Code »

    The Montgomery Multiply, Montgomery Square, and Multiple-Precision
    Multiply instructions work by loading a combination of the floating
    point and multiple register windows worth of integer registers
    with the inputs.

    These values are 64-bit. But for 32-bit userland processes we only
    save the low 32-bits of each integer register during a register spill.
    This is because the register window save area is in the user stack and
    has a fixed layout.

    Therefore, the only way to use these instruction in 32-bit mode is to
    perform the following sequence:

    1) Load the top-32bits of a choosen integer register with a sentinel,
    say "-1". This will be in the outer-most register window.

    The idea is that we're trying to see if the outer-most register
    window gets spilled, and thus the 64-bit values were truncated.

    2) Load all the inputs for the montmul/montsqr/mpmul instruction,
    down to the inner-most register window.

    3) Execute the opcode.

    4) Traverse back up to the outer-most register window.

    5) Check the sentinel, if it's still "-1" store the results.
    Otherwise retry the entire sequence.

    This retry is extremely troublesome. If you're just unlucky and an
    interrupt or other trap happens, it'll push that outer-most window to
    the stack and clear the sentinel when we restore it.

    We could retry forever and never make forward progress if interrupts
    arrive at a fast enough rate (consider perf events as one example).
    So we have do limited retries and fallback to software which is
    extremely non-deterministic.

    Luckily it's very straightforward to provide a mechanism to let
    32-bit applications use a 64-bit stack. Stacks in 64-bit mode are
    biased by 2047 bytes, which means that the lowest bit is set in the
    actual %sp register value.

    So if we see bit zero set in a 32-bit application's stack we treat
    it like a 64-bit stack.

    Runtime detection of such a facility is tricky, and cumbersome at
    best. For example, just trying to use a biased stack and seeing if it
    works is hard to recover from (the signal handler will need to use an
    alt stack, plus something along the lines of longjmp). Therefore, we
    add a system call to report a bitmask of arch specific features like
    this in a cheap and less hairy way.

    With help from Andy Polyakov.

    Signed-off-by: David S. Miller

    David S. Miller
     

25 May, 2012

1 commit

  • 456d3d424   sparc64: Fix several bugs in quad floating point emulation. ... Browse Code »

    UltraSPARC-T2 and later do not use the fp_exception_other trap and do
    not set the floating point trap type field in the %fsr at all when you
    try to execute an unimplemented FPU operation.

    Instead, it uses the illegal_instruction trap and it leaves the
    floating point trap type field clear.

    So we should not validate the %fsr trap type field when do_mathemu()
    is invoked from the illegal instruction handler.

    Also, the floating point trap type field is 3 bits, not 4 bits.

    Signed-off-by: David S. Miller

    David S. Miller
     

29 Mar, 2012

1 commit

01 Jul, 2011

1 commit

  • a8b0ca17b   perf: Remove the nmi parameter from the swevent and overflow interface ... Browse Code »
    1

    The nmi parameter indicated if we could do wakeups from the current
    context, if not, we would set some state and self-IPI and let the
    resulting interrupt do the wakeup.

    For the various event classes:

    - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
    the PMI-tail (ARM etc.)
    - tracepoint: nmi=0; since tracepoint could be from NMI context.
    - software: nmi=[0,1]; some, like the schedule thing cannot
    perform wakeups, and hence need 0.

    As one can see, there is very little nmi=1 usage, and the down-side of
    not using it is that on some platforms some software events can have a
    jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).

    The up-side however is that we can remove the nmi parameter and save a
    bunch of conditionals in fast paths.

    Signed-off-by: Peter Zijlstra
    Cc: Michael Cree
    Cc: Will Deacon
    Cc: Deng-Cheng Zhu
    Cc: Anton Blanchard
    Cc: Eric B Munson
    Cc: Heiko Carstens
    Cc: Paul Mundt
    Cc: David S. Miller
    Cc: Frederic Weisbecker
    Cc: Jason Wessel
    Cc: Don Zickus
    Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

31 Mar, 2011

1 commit

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