Eric Lee / smarc-fsl-linux-kernel

21 Aug, 2020

3 commits

  • 66aa38801   m68k: get rid of zeroing destination on error in csum_and_copy_from_user() ... Browse Code »

    Signed-off-by: Al Viro

    Al Viro
     
  • c693cc467   saner calling conventions for csum_and_copy_..._user() ... Browse Code »

    All callers of these primitives will
    * discard anything we might've copied in case of error
    * ignore the csum value in case of error
    * always pass 0xffffffff as the initial sum, so the
    resulting csum value (in case of success, that is) will never be 0.

    That suggest the following calling conventions:
    * don't pass err_ptr - just return 0 on error.
    * don't bother with zeroing destination, etc. in case of error
    * don't pass the initial sum - just use 0xffffffff.

    This commit does the minimal conversion in the instances of csum_and_copy_...();
    the changes of actual asm code behind them are done later in the series.
    Note that this asm code is often shared with csum_partial_copy_nocheck();
    the difference is that csum_partial_copy_nocheck() passes 0 for initial
    sum while csum_and_copy_..._user() pass 0xffffffff. Fortunately, we are
    free to pass 0xffffffff in all cases and subsequent patches will use that
    freedom without any special comments.

    A part that could be split off: parisc and uml/i386 claimed to have
    csum_and_copy_to_user() instances of their own, but those were identical
    to the generic one, so we simply drop them. Not sure if it's worth
    a separate commit...

    Signed-off-by: Al Viro

    Al Viro
     
  • cc44c17ba   csum_partial_copy_nocheck(): drop the last argument ... Browse Code »

    It's always 0. Note that we theoretically could use ~0U as well -
    result will be the same modulo 0xffff, _if_ the damn thing did the
    right thing for any value of initial sum; later we'll make use of
    that when convenient.

    However, unlike csum_and_copy_..._user(), there are instances that
    did not work for arbitrary initial sums; c6x is one such.

    Signed-off-by: Al Viro

    Al Viro
     

30 May, 2020

1 commit

31 May, 2019

1 commit

  • 2874c5fd2   treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 ... Browse Code »

    Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

02 Nov, 2017

1 commit

  • b24413180   License cleanup: add SPDX GPL-2.0 license identifier to files with no license ... Browse Code »

    Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

29 Mar, 2017

1 commit

25 Feb, 2017

1 commit

  • 849de0cd2   m68k: replace gcc specific macros with ones from compiler.h ... Browse Code »

    There is which provides macros for various gcc
    specific constructs. Eg: __weak for __attribute__((weak)). I've
    cleaned all instances of gcc specific attributes with the right macros
    for all files under /arch/m68k

    Link: http://lkml.kernel.org/r/1485540901-1988-3-git-send-email-gidisrael@gmail.com
    Signed-off-by: Gideon Israel Dsouza
    Cc: Greg Ungerer
    Cc: Geert Uytterhoeven
    Cc: Paul Gortmaker
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Gideon Israel Dsouza
     

25 Dec, 2016

1 commit

08 Aug, 2016

1 commit

15 Mar, 2015

1 commit

25 Jun, 2013

2 commits

  • 631d8b674   m68k/uaccess: Fix asm constraints for userspace access ... Browse Code »

    When compiling a MMU kernel with CPU_HAS_ADDRESS_SPACES=n (e.g. "MMU=y
    allnoconfig": "echo CONFIG_MMU=y > allno.config && make KCONFIG_ALLCONFIG=1
    allnoconfig"), we use plain "move" instead of "moves", and I got:

    CC arch/m68k/lib/uaccess.o
    {standard input}: Assembler messages:
    {standard input}:47: Error: operands mismatch -- statement `move.b %a0,(%a1)' ignored

    This happens because plain "move" doesn't support byte transfers between
    memory and address registers, while "moves" does.

    Fix the asm constraints for __generic_copy_from_user(),
    __generic_copy_to_user(), and __clear_user() to only use data registers
    when accessing userspace.

    Also, relax the asm constraints for 16-bit userspace accesses in
    __put_user() and __get_user(), as both "move" and "moves" do support
    such transfers between memory and address registers.

    Signed-off-by: Geert Uytterhoeven

    Geert Uytterhoeven
     
  • d346a5db0   m68k: Remove inline strcpy() and strcat() implementations ... Browse Code »

    Gcc may replace calls to standard string functions by open code and/or
    calls to other standard string functions. If the replacement function is
    not available out-of-line, link errors will happen.

    To avoid this, the out-of-line versions were provided by
    arch/m68k/lib/string.c, but they were usually not linked in anymore as
    typically none of its symbols are referenced by built-in code.
    However, if any module would need them, they would not be available.

    Hence remove the inline strcpy() and strcat() implementations, remove
    arch/m68k/lib/string.c, and let the generic string library code handle it.

    Impact on a typical kernel build seems minimal or nonexistent:

    - .text : 0x00001000 - 0x002aac74 (2728 KiB)
    - .data : 0x002ada48 - 0x00392148 ( 914 KiB)
    + .text : 0x00001000 - 0x002aacf4 (2728 KiB)
    + .data : 0x002adac8 - 0x00392148 ( 914 KiB)

    See also commit e00c73ee05dc38ecaccced55d4f5fc58b0b769f7 ("m68k: Remove
    inline strlen() implementation").

    Signed-off-by: Geert Uytterhoeven

    Geert Uytterhoeven
     

17 Apr, 2013

1 commit

  • e00c73ee0   m68k: Remove inline strlen() implementation ... Browse Code »

    GCC can replace a strncat() call with constant second argument into a
    strlen + store, which results in a link error:

    ERROR: "strlen" [net/ipv4/ip_tunnel.ko] undefined!

    The inline function is a simple for loop in C. Other architectures
    either use an asm optimized variant, or use the generic function from
    lib/string.c.

    Reported-by: Geert Uytterhoeven
    Signed-off-by: Michal Marek
    Signed-off-by: Geert Uytterhoeven

    Michal Marek
     

05 Dec, 2012

1 commit

  • 423c01eac   m68k: fix unused variable warning in mempcy.c ... Browse Code »

    When compiling for original 68000 or ColdFire targets you will get the
    following warning when compiling arch/m68k/lib/memcpy.c:

    CC arch/m68k/lib/memcpy.o
    arch/m68k/lib/memcpy.c: In function ‘__builtin_memcpy’:
    arch/m68k/lib/memcpy.c:13:15: warning: unused variable ‘temp1’

    This is easily fixed by moving the definition of temp1 into the code block
    where it is used.

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     

10 Jun, 2012

1 commit

06 Jun, 2012

1 commit

30 Dec, 2011

1 commit

  • e08d703cc   m68k: modify user space access functions to support ColdFire CPUs ... Browse Code »

    Modify the user space access functions to support the ColdFire V4e cores
    running with MMU enabled.

    The ColdFire processors do not support the "moves" instruction used by
    the traditional 680x0 processors for moving data into and out of another
    address space. They only support the notion of a single address space,
    and you use the usual "move" instruction to access that.

    Create a new config symbol (CONFIG_CPU_HAS_ADDRESS_SPACES) to mark the
    CPU types that support separate address spaces, and thus also support
    the sfc/dfc registers and the "moves" instruction that go along with that.

    The code is almost identical for user space access, so lets just use a
    define to choose either the "move" or "moves" in the assembler code.

    Signed-off-by: Greg Ungerer
    Acked-by: Matt Waddel
    Acked-by: Kurt Mahan
    Acked-by: Geert Uytterhoeven

    Greg Ungerer
     

24 Dec, 2011

2 commits

  • 84f3fb7a2   m68k: handle presence of 64bit mul/div instructions cleanly ... Browse Code »

    The traditional 68000 processors and the newer reduced instruction set
    ColdFire processors do not support the 32*32->64 multiply or the 64/32->32
    divide instructions. This is not a difference based on the presence of
    a hardware MMU or not.

    Create a new config symbol to mark that a CPU type doesn't support the
    longer multiply/divide instructions. Use this then as a basis for using
    the fast 64bit based divide (in div64.h) and for linking in the extra
    libgcc functions that may be required (mulsi3, divsi3, etc).

    Signed-off-by: Greg Ungerer
    Acked-by: Geert Uytterhoeven

    Greg Ungerer
     
  • 7f73bafc4   m68k: simpler m68k and ColdFire CPU's can use generic csum code ... Browse Code »

    We have two implementations of the IP checksuming code for the m68k arch.
    One uses the more advanced instructions available in 68020 and above
    processors, the other uses the simpler instructions available on the
    original 68000 processors and the modern ColdFire processors.

    This simpler code is pretty much the same as the generic lib implementation
    of the IP csum functions. So lets just switch over to using that. That
    means we can completely remove the checksum_no.c file, and only have the
    local fast code used for the more complex 68k CPU family members.

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     

18 Oct, 2011

1 commit

  • f230e80b4   m68k: fix memcpy to unmatched/unaligned source and dest on 68000 ... Browse Code »

    The original 68000 processors cannot copy 16bit or larger quantities from
    odd addresses. All newer members of the 68k family (including ColdFire)
    can do this.

    In the current memcpy implementation after trying to align the destination
    address to a 16bit boundary if we end up with an odd source address we go
    off and try to copy multi-byte quantities from it. This will trap on the
    68000.

    The only solution if we end with an odd source address is to byte wise
    copy the whole memcpy region. We only need to do this if we are supporting
    original 68000 processors.

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     

25 Jul, 2011

1 commit

  • 7c946199c   m68k: merge and clean up delay.h files ... Browse Code »

    The real difference between the mmu and non-mmu varients of the delay.h
    files has nothing to do with having an mmu or not. It is processor family
    differences that means slightly different code. Merge the delay_mm.h and
    delay_no.h files back into a single file.

    The primarly difference we need to deal with is whether the processor
    supports a 32bit * 32bit -> 64bit multiply. Without it we need to do some
    shift scaling as well as use a 32bit * 32bit -> 32bit multiply. If building
    for a multi-CPU type kernel then we must use the simpler mult/shift scaling.

    This version of delay code allows the CPU32 family to use a 64bit mul,
    since it supports this instruction, the old code did not.

    The changes use macros where appropriate to try and optimize constant sized
    udelay times. And it removes the use of a fixed lib function for the non-mmu
    case. Code size on typical kernel configurations is similar, or only larger
    by a few tens of bytes.

    Also removed the unused muldiv() code from delay_mm.h.

    Build and run tested on ColdFire and ARAnyM. Build tested only on 68328
    and 68360 (CPU32).

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     

14 Jun, 2011

1 commit

  • 734c3ce3b   m68k: use kernel processor defines for conditional optimizations ... Browse Code »

    Older m68k-linux compilers will include pre-defined symbols that
    confuse what processor it is being targeted for. For example gcc-4.1.2
    will pre-define __mc68020__ even if you specify the target processor
    as -m68000 on the gcc command line. Newer versions of gcc have this
    corrected.

    In a few places the m68k code uses defined(__mc68020__) for optimizations
    that include instructions that are specific to the CPU 68020 and above.
    When compiling with older compilers this will be true even when we have
    selected to compile for the older 68000 processors.

    Switch to using the kernel processor defines, CONFIG_M68020 and friends.

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     

24 May, 2011

7 commits

25 Mar, 2011

1 commit

  • 66d857b08   m68k: merge m68k and m68knommu arch directories ... Browse Code »

    There is a lot of common code that could be shared between the m68k
    and m68knommu arch branches. It makes sense to merge the two branches
    into a single directory structure so that we can more easily share
    that common code.

    This is a brute force merge, based on a script from Stephen King
    , which was originally written by Arnd Bergmann
    .

    > The script was inspired by the script Sam Ravnborg used to merge the
    > includes from m68knommu. For those files common to both arches but
    > differing in content, the m68k version of the file is renamed to
    > _mm. and the m68knommu version of the file is moved into the
    > corresponding m68k directory and renamed _no. and a small
    > wrapper file . is used to select between the two version. Files
    > that are common to both but don't differ are removed from the m68knommu
    > tree and files and directories that are unique to the m68knommu tree are
    > moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
    >
    > To select between the the versions of the files, the wrapper uses
    >
    > #ifdef CONFIG_MMU
    > #include _mm.
    > #else
    > #include _no.
    > #endif

    On top of this file merge I have done a simplistic merge of m68k and
    m68knommu Kconfig, which primarily attempts to keep existing options and
    menus in place. Other than a handful of options being moved it produces
    identical .config outputs on m68k and m68knommu targets I tested it on.

    With this in place there is now quite a bit of scope for merge cleanups
    in future patches.

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     

16 Feb, 2011

1 commit

  • f9d693d23   m68k: remove arch specific non-optimized memcmp() ... Browse Code »

    The m68k arch implements its own memcmp() function. It is not optimized
    in any way (it is the most strait forward coding of memcmp you can get).
    Remove it and use the kernels standard memcmp() implementation.

    This also goes part of the way to fixing a regression caused by commit
    ea61bc461d09e8d331a307916530aaae808c72a2 ("m68k/m68knommu: merge MMU and
    non-MMU string.h"), which breaks non-coldfire non-mmu builds (which is
    the 68x328 and 68360 families). They currently have no memcmp() function
    defined, since there is none in the m68knommu/lib functions.

    Signed-off-by: Greg Ungerer
    Acked-by: Geert Uytterhoeven

    Greg Ungerer
     

21 Jul, 2008

1 commit

  • a0c14d28d   Stringify support commas ... Browse Code »

    > This is a no-no for those archs that still use -traditional.
    > > I dunno if this is a problem for you at the moment and the
    > > right fix is anyway to nuke -traditional.
    > >
    > > Sam

    Signed-off-by: Mathieu Desnoyers
    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Linus Torvalds

    Mathieu Desnoyers
     

22 May, 2008

1 commit

  • 337e3c48e   provide out-of-line strcat() for m68k ... Browse Code »

    Whether we sidestep it in init/main.c or not, such situations
    will arise again; compiler does generate calls of strcat()
    on optimizations, so we really ought to have an out-of-line
    version...

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

17 Apr, 2008

1 commit

  • 64ac24e73   Generic semaphore implementation ... Browse Code »
    43

    Semaphores are no longer performance-critical, so a generic C
    implementation is better for maintainability, debuggability and
    extensibility. Thanks to Peter Zijlstra for fixing the lockdep
    warning. Thanks to Harvey Harrison for pointing out that the
    unlikely() was unnecessary.

    Signed-off-by: Matthew Wilcox
    Acked-by: Ingo Molnar

    Matthew Wilcox
     

18 Jul, 2007

1 commit

15 May, 2007

1 commit

  • 3c46bdcae   m68k: implement __clear_user() ... Browse Code »

    m68k: implement __clear_user(), which is needed by fs/signalfd.c

    Since we always let the MMU do all checking, clear_user() and __clear_user()
    are identical. The old clear_user() is renamed to __clear_user() for
    consistency.

    Signed-off-by: Geert Uytterhoeven
    Cc: Davide Libenzi
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Geert Uytterhoeven
     

05 May, 2007

1 commit

03 Dec, 2006

1 commit

06 Oct, 2006

1 commit