Skip to content
Snippets Groups Projects
  1. Feb 20, 2020
  2. Jan 10, 2020
  3. May 24, 2019
  4. Sep 15, 2018
  5. Sep 11, 2018
  6. Jun 18, 2018
  7. May 07, 2018
    • Tom Rini's avatar
      SPDX: Convert all of our single license tags to Linux Kernel style · 83d290c5
      Tom Rini authored
      
      When U-Boot started using SPDX tags we were among the early adopters and
      there weren't a lot of other examples to borrow from.  So we picked the
      area of the file that usually had a full license text and replaced it
      with an appropriate SPDX-License-Identifier: entry.  Since then, the
      Linux Kernel has adopted SPDX tags and they place it as the very first
      line in a file (except where shebangs are used, then it's second line)
      and with slightly different comment styles than us.
      
      In part due to community overlap, in part due to better tag visibility
      and in part for other minor reasons, switch over to that style.
      
      This commit changes all instances where we have a single declared
      license in the tag as both the before and after are identical in tag
      contents.  There's also a few places where I found we did not have a tag
      and have introduced one.
      
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      83d290c5
  8. Jan 30, 2018
  9. Oct 03, 2017
  10. Oct 19, 2016
  11. Sep 23, 2016
  12. Aug 15, 2016
  13. May 27, 2016
  14. May 17, 2016
  15. Jan 19, 2016
  16. Nov 09, 2015
    • Måns Rullgård's avatar
      Replace "extern inline" with "static inline" · 44d0677a
      Måns Rullgård authored
      
      A number of headers define functions as "extern inline" which is
      causing problems with gcc5.  The reason is that starting with
      version 5.1, gcc defaults to the standard C99 semantics for the
      inline keyword.
      
      Under the traditional GNU inline semantics, an "extern inline"
      function would never create an external definition, the same
      as inline *without* extern in C99.  In C99, and "extern inline"
      definition is simply an external definition with an inline hint.
      In short, the meanings of inline with and without extern are
      swapped between GNU and C99.
      
      The upshot is that all these definitions in header files create
      an external definition wherever those headers are included,
      resulting in multiple definition errors at link time.
      
      Changing all these functions to "static inline" fixes the problem
      since this works as desired in all gcc versions.  Although the
      semantics are slightly different (a static inline definition may
      result in an actual function being emitted), it works as intended
      in practice.
      
      This patch also removes extern prototype declarations for the
      changed functions where they existed.
      
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      44d0677a
  17. Nov 05, 2015
  18. Mar 28, 2015
  19. Mar 06, 2015
  20. Jul 22, 2014
    • Masahiro Yamada's avatar
      m68k: define __kernel_size_t as unsinged int again · fbe79a17
      Masahiro Yamada authored
      Commit ddc94378 changed the definition of __kernel_size_t
      from unsigned int to unsigned long.
      
      It is true that it fixed warnings on some crosstools
      but it increased warnings on the others.
      
      The problem is that we cannot see consistency in terms of
      the typedef of __kernel_size_t on M68K architecture.
      
      However, I'd like to suggest to have __kernel_size_t to be
      unsigned int again.
      
      Rationale:
      
      [1] Linux Kernel defines __kernel_size_t on M68K as unsigned int.
          Let's stick to the Linux's way.
      
      [2] We want to build boards with popular pre-built toolchains,
          not the one locally-built by indivisuals.
          I think m68-linux-gcc which can be downloaded from www.kernel.org
          is the candidate for our _recommended_ toolchains.
      
      With this patch, all the m68k boards can be built without any warnings.
      
      Give it a try with the following crosstools:
      
      https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
      x86_64-gcc-4.6.3-nolibc_m68k-linux.tar.xz
      
      or
      
      https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/
      
      
      x86_64-gcc-4.9.0-nolibc_m68k-linux.tar.xz
      
      (The latter is newer.)
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Jason Jin <Jason.jin@freescale.com>
      fbe79a17
  21. Jun 19, 2014
  22. Jun 11, 2014
  23. May 12, 2014
    • Masahiro Yamada's avatar
      bd_info: remove bi_barudrate member from struct bd_info · 8e261575
      Masahiro Yamada authored
      
      gd->bd->bi_baudrate is a copy of gd->baudrate.
      
      Since baudrate is a common feature for all architectures,
      keep gd->baudrate only.
      
      It is true that bi_baudrate was passed to the kernel in that structure
      but it was a long time ago.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Tom Rini <trini@ti.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Heiko Schocher <hs@denx.de>
      Acked-by: Michal Simek <monstr@monstr.eu> (For microblaze)
      8e261575
  24. Nov 08, 2013
  25. Oct 14, 2013
  26. Jul 24, 2013
  27. Jul 23, 2013
  28. Jun 27, 2013
  29. Mar 15, 2013
    • Simon Glass's avatar
      Introduce generic link section.h symbol files · 18652864
      Simon Glass authored
      
      We create a separate header file for link symbols defined by the link
      scripts. It is helpful to have these all in one place and try to
      make them common across architectures. Since Linux already has a similar
      file, we bring this in even though many of the symbols there are not
      relevant to us.
      
      Each architecture has its own asm/sections.h where symbols specifc to
      that architecture can be added. For now everything except AVR32 just
      includes the generic header.
      
      One change is needed in arch/avr32/lib/board.c to make this conversion
      work.
      
      Reviewed-by: Tom Rini <trini@ti.com> (version 5)
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      18652864
  30. Feb 04, 2013
  31. Feb 01, 2013
    • Simon Glass's avatar
      Add architecture-specific global data · 5cb48582
      Simon Glass authored
      
      We plan to move architecture-specific data into a separate structure so
      that we can make the rest of it common.
      
      As a first step, create struct arch_global_data to hold these fields.
      Initially it is empty.
      
      This patch applies to all archs at once. I can split it if this is really
      a pain.
      
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      5cb48582
  32. Dec 11, 2012
    • Simon Glass's avatar
      Add strcasecmp() and strncasecmp() · b1f17bf5
      Simon Glass authored
      
      strncasecmp() is present as strnicmp() but disabled. Make it available
      and define strcasecmp() also. There is a only a small performance penalty
      to having strcasecmp() call strncasecmp(), so do this instead of a
      standalone function, to save code space.
      
      Update the prototype in arch-specific headers as needed to avoid warnings.
      
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      b1f17bf5
  33. Oct 24, 2012
Loading